DDD-建模过程分析

Eric Evans的“Domain-Driven Design领域驱动设计”，简称DDD，Evans DDD是一套综合软件系统分析和设计的面向对象建模方法，其核心就是建立正确的足够精良且符合业务需求的领域模型。

领域建模过程

目前广为流行的项目开发模式如瀑布模型、敏捷开发模型等，都将软件分析与设计作为两个独立的阶段，这样的割裂导致需求分析的结果往往无法直接进行设计编程，而实现的软件结果往往不能够很好的适应真实的业务需求，无法达到用户的预期，而且不能够快速适应需求的变化。

领域驱动设计则是将二者有机地结合起来，以统一的领域通用语言（不一定是UML）进行系统建模，进行系统的分析和设计工作，即该领域专业的业务人员（领域专家） 和 软件开发人员通过领域模型进行需求沟通，彼此共享领域知识，确立符合真实业务需求的领域模型。
其本质上就是对面向对象分析过程的一个扩展和延伸。

领域表示正在处理的现实世界中复杂的业务逻辑或规则构成的问题域；
领域模型是对现实世界真实业务的抽象描述，与任何技术实现都无关；
在需求阶段表现为分析模型，设计阶段表现为设计模型（UML模型）。前期它可以为通过正式或非正式的UML图、草图、文字说明等进行描述，形成领域专家和开发人员都能理解的业务领域模型，后期则需要开发人员对分析模型进行再次凝练提取，成为较为完整的UML模型。

其领域建模分析过程如下图所示：
子域 是整个业务领域的一部分，通常这个与微服务划分的粒度有些关系。
在一个庞大的复杂系统中，通常大多数的领域模型都过于复杂而划分为若干个子业务系统，这些子业务系统可以成为一个子域；若是子业务系统继续拆分，子域也可继续向下兼容，系统拆分的粒度影响子域的多少。在系统分析设计中，明确清晰的限界上下文无疑是最好的选择，但通常情况下系统边界未必那么明确……
子域类型通常有如下三种：核心域、支撑子域、通用子域。

• 核心域（Sub Domain）：核心业务，可理解为一个有明确限界上下文的定义明确的业务领域模型，是项目的核心业务的体现，需要团队精心打造重点关注的核心模块。
• 支撑子域（Supporting Subdomain）：支撑核心域的相关功能，这类通常需要定制开发，根据核心子域的相关内容进行定制
• 通用子域（Generic Subdomain）：可以理解为现成的解决方案，拿来即用，也是用来辅助核心子域，但不需要像支撑子域那样个性化定制。

开发人员参与的必要性： 领域模型分析与软件设计实现通常不是一个等价的映射，构建的模型未必足够精良能够完全适应软件的设计实现，故需要将开发人员来加入领域模型分析过程中，在模型构建时候即开始考虑软件的设计实现。这样有了开发人员反馈就能更好的保证模型的质量，也能够帮助开发者理解业务，保证软件最大程度满足需求结果。

领域模型设计

在领域模型设计过程中，通常有两种模式：

1. 基于数据库的建模：Database Modeling，

   通过数据抽象系统关系，即传统数据库分析设计。该种模式实际上就是一种典型的贫血模型，通过数据库映射的实体类只有对应的属性，成为了只有getter和setter方法的数据载体，而没有具体行为，相应的行为要通过Service层去实现，随着业务升级积累，会出现胖服务层和贫血的领域模型，维护起来会越发乏力。即便如此，该种模式仍是广泛应用在软件开发领域。

2. 基于对象的建模： Object Modeling，

   通过面向对象方式抽象系统关系，也就是面向对象设计。毫无疑问，在面向对象编程环境中，面向对象无疑是领域建模最佳方式。通过面向对象构建的领域模型，因为有类的继承、封装、多态等特性显得生动许多，不仅包含自身属性状态，还包括有方法行为等，即充血的领域模型。一些Service层的行为凝练为领域服务，Service层则变薄了，领域模型则丰富了行为。

假设内存空间无限，不考虑持久化，面向对象建模无疑是最佳选择。

参考资料：

[1] https://zhuanlan.zhihu.com/p/27753540
[2] https://zhuanlan.zhihu.com/p/37710646