领域驱动设计-day7

    通过之前的学习，对DDD从设计到开发已经有了一定的了解。DDD作为指导微服务建模的指南，讲了从战略设计 到战术设计的方法。但没有讲解微服务拆分，跟设计的原则。今天就学习下微服务拆分的原则，同时也是领域设计的最有一节。

一、微服务设计和拆分要坚持哪些原则？

微服务设计原则

微服务设计原则中，如高内聚低耦合、复用、单一职责等这些常见的设计原则在此就不赘述

了，主要强调下面这几条：

 

第一条：要领域驱动设计，而不是数据驱动设计，也不是界面驱动设计。

微服务设计首先应建立领域模型，确定逻辑和物理边界以及领域对象后，然后才开始微服务

的拆分和设计。而不是先定义数据模型和库表结构，也不是前端界面需要什么，就去调整核

心领域逻辑代码。在设计时应该将外部需求从外到内逐级消化，尽量降低对核心领域层逻辑

的影响。

 

第二条：要边界清晰的微服务，而不是泥球小单体。

微服务上线后其功能和代码也不是一成不变的。随着需求或设计变化，领域模型会迭代，微

服务的代码也会分分合合。边界清晰的微服务，可快速实现微服务代码的重组。微服务内聚

合之间的领域服务和数据库实体原则上应杜绝相互依赖。你可通过应用服务编排或者事件驱

动，实现聚合之间的解耦，以便微服务的架构演进。

第三条：要职能清晰的分层，而不是什么都放的大箩筐。

分层架构中各层职能定位清晰，且都只能与其下方的层发生依赖，也就是说只能从外层调用

内层服务，内层通过封装、组合或编排对外逐层暴露，服务粒度也由细到粗。应用层负责服

务的组合和编排，不应有太多的核心业务逻辑，领域层负责核心领域业务逻辑的实现。各层

应各司其职，职责边界不要混乱。在服务演进时，应尽量将可复用的能力向下层沉淀。

 

第四条：要做自己能 hold 住的微服务，而不是过度拆分的微服务。

微服务过度拆分必然会带来软件维护成本的上升，比如：集成成本、运维成本、监控和定位

问题的成本。企业在微服务转型过程中还需要有云计算、DevOps、自动化监控等能力，而

一般企业很难在短时间内提升这些能力，如果项目团队没有这些能力，将很难 hold 住这些

微服务。

微服务拆分需要考虑哪些因素？

1. 基于领域模型

基于领域模型进行拆分，围绕业务领域按职责单一性、功能完整性拆分。

2. 基于业务需求变化频率

识别领域模型中的业务需求变动频繁的功能，考虑业务变更频率与相关度，将业务需求变动

较高和功能相对稳定的业务进行分离。这是因为需求的经常性变动必然会导致代码的频繁修

改和版本发布，这种分离可以有效降低频繁变动的敏态业务对稳态业务的影响。

3. 基于应用性能

识别领域模型中性能压力较大的功能。因为性能要求高的功能可能会拖累其它功能，在资源

要求上也会有区别，为了避免对整体性能和资源的影响，我们可以把在性能方面有较高要求

的功能拆分出去。

4. 基于安全边界

有特殊安全要求的功能，应从领域模型中拆分独立，避免相互影响。

5. 基于技术异构等因素

领域模型中有些功能虽然在同一个业务域内，但在技术实现时可能会存在较大的差异，也就

是说领域模型内部不同的功能存在技术异构的问题。由于业务场景或者技术条件的限制，有

的可能用.NET，有的则是 Java，有的甚至大数据架构。对于这些存在技术异构的功能，可

以考虑按照技术边界进行拆分。