领域服务的竖向裁切, 横向裁切 - 模块化架构

1. 背景：

    在复杂多变的业务场景中，在开发完一个项目后，往往需要为多个业务方提供共性的业务能力，但是不同的业务方又会有个性的需求，如何在保证软件的核心能力的稳固的同时，同时低成本地支持拓展性？

2. 可行方式：

    通常通过业务抽象实现是可以对多变但同质业务进行支持，只是有些时候通过抽象无法解决，或者解决成本过高，过度的抽象往往也会增加系统的复杂度，那么这个时候可以通过应用功能模块化 来定制化组合拓展应用程序，同时也能复用部分业务能力

3. 竖向裁切

    通过DDD来划分领域边界，同时也可以作为微服务拆分的依据。通过建立业务层面的领域模型和技术层面的微服务边界划分，实现不同微服务独立提供业务能力。同时应对不同区域对于业务能力的取舍，也可以方便地通过微服务的裁切组合，服务之间通过消息适配器耦合，来提供个性化的服务；
解耦合的方式：通过微服务独立部署，然后通过消息适配器来实现弱耦合，消息适配器是易变的，个性的。

4. 横向裁切

    通常在领域应用的分层中，越靠近内核的 越是不易变的，共性的逻辑；越是外层的 越是易变的，个性的逻辑。通过对不同layer进行代码隔离，可以达到继承覆盖的方式来进行已有功能的拓展，替换jar包的方式来实现易变逻辑的完全替代。来实现底层领域能力的复用，并支持业务多样性。
优点：个性需求，从代码到服务层面都进行分离，不同业务方基本不会互相影响，同时又能复用公共的底层能力代码
缺点：重新组合的服务，需要独立部署，产生数据隔离。

4.1 不同Lay替换和拓展的方式

4.1.1 Domain Model

    由于Domain Model存有最核心的业务逻辑，需要修改这里的逻辑应该是共性的逻辑，替换或者拓展的可能性比较小；

4.1.2 Domain Service

    Domain Service 直接依赖Domain Model，负责对多个或者单个领域能力进行包装组合，如果这里的业务逻辑需要改变的话，可以通过继承Service并重写的方式来改变指定逻辑，适合修改部分少，同时需要复用部分原有逻辑的场景；又或者直接写一个新的Domain Service替换掉原有的jar，因为Domain Controller通过Service API来耦合Domain Service的，所以不会把影响向上传播。

4.1.3 Domain Controller

    拓展逻辑基本和Domain Service相同

4.2 常见的业务差异点：

1. 个性化的 字段需求，包含录入，查询，搜索场景，需要通过动态字段，以及OLAP进行适配

2. 个性化的 校验逻辑的需求，根据输入的信息，关联的外部信息，核心的状态信息 进行个性化的逻辑分支判断，通过逻辑剥离到Domain Controller层进行适配

3. 个性化的 状态机流转，比如跨状态流转，某些状态对于某些业务来说是不需要的

5. 关联文章

Unlocking the Power of Modular Architecture and DDD

CQRS pattern