近年微服务架构兴起，对於规模较小的开发团队而言，一开始就拆分为多个微服务是个沉重的负担，所以大多还是从单体式架构 monolithic 出发，往後再逐步拆分为微服务。虽然这种开发方式广泛被采用，但实务上并不是所有团队都能轻松转换至微服务架构，这取决於单体式架构里的各个功能实作上是否能低耦合，甚至模组化。

另一方面，即使往後将各个功能拆分成微服务，因为通常拆分的时间点不一, 或是由不同的工程师负责实作，如果没有事先规划及规定统一的作法，就容易导致各个微服务在基础设施功能方面的实作方式上有所差异，提高了往後开发及维运的成本。

本专案是以模组化为准则的单体式架构，在底层的基础设施函式库上建立多个子专案，当未来要将子专案拆分为微服务时，能把转换工作降至最低。规划子专案的方式，除了可以采用 Backend for Frontend (BFF) 的方式，简单地把多个前端与有商业逻辑的後端分开之外，也可以遵循 DDD 的概念，将每个子专案对应到一个 Bounded Context。

Gradle Multi-Project Builds

在专案结构上，为了让各个子专案尽量独立不耦合，我采用 Gradle Multi-Projects Build 分隔子专案，强迫开发者意识到这是一段跨专案依赖呼叫的程序码，未来拆分为微服务时，将会从直接函式呼叫改为远端呼叫。

Multi-Project Architecture

在架构设计方面，每个子专案都会有一个 projectId，因为底层的基础设施函式库多考虑了 project 维度，而且产生的资料也已经记录了 projectId，当未来要把子专案拆分为微服务时，将会轻松许多，例如 Logging 功能会记录这个请求是由那个 project 处理。除了 projectId 之外，每个子专案还可以定义自己的 User Type 及 User Role，还有 Notification Type，让商业逻辑 Domain Model Object 可以独立分开，然而底层的 API 权限检查、寄送讯息通知…等功能实作程序码都是相同的。

Ktor Module

在实作及部署方面，每个子专案都是一个 Ktor Module，我们可以根据 Ktor Module 本身的设计，修改设定档中的 ktor.application.modules 属性值来决定要部署那些子专案。如果一个子专案没有被部署，则执行期不会进行任何初始化动作，也就不会部署任何 API。理论上，我们可以把 A, B 2个子专案分开部署，然後设定 nginx 或 API Gateway 重新导向，如果发现 A 专案紧急有 Bug 需要修正，那麽 B 专案将不会被影响，即使 A, B 都是在同一个单体式架构开发的。不过我觉得这是单体式架构不得已的作法，所以也不是很推荐采用就是了。

这2天已说明我的 side project 目标、设计概念、实作项目及要解决的问题，明天开始就要进入实作程序码。