DDD领域模型梳理的路径和方法

一：明确问题域
深入了解业务背景，并在这个背景下分析出来需要解决的问题。
二：梳理业务概念（High Level，不关注技术实现）
基于要解决的问题，我们来梳理下整个业务过程中存在的业务概念，统一概念的定义是便于大家理解业务逻辑的第一步
业务概念是便于理解业务，但是不仅限于此，后续细化子域并抽象领域模型就依赖对这些概念的分解
三：梳理整体业务数据流，识别限界上下文（Bounded Context）
根据上述分析，对问题域对应的业务概念进行一定粗略梳理之后，对核心业务概念大致梳理了命名和定义，我们可以认为整个解决上述问题域的解决方案是一个最外层的上下文。那么，将这个庞大的上下文的这些概念从业务作业的操作流角度串联起来，并进一步从这些业务作业背后的知识专业性以及业务职责划分等维度，进一步界定和细化下一层的各个独立的上下文，并为每个上下文设计领域模型，并将其映射到具体这个上下文内的解决方案上。
四：细化子域
这里提供一些方法以及原则供参考：
A) 梳理子域概念
抽象子域内的核心概念，并建立概念之间的关系，进行初步的静态建模。
B) 提炼业务规则
这里需要提炼出该子域内我们关注的各种业务规则，DDD中叫不变性（invariants），通用的例如唯一性规则等，建议一条条列出来，后续验证模型的完整性时可以一项项来看是否这些规则都覆盖到了
C) 枚举业务场景
分辨出核心场景
D) 分析业务流程
基于业务场景内部以及各个场景之间的协同识别出核心业务流程。
E) 基于场景与流程分析模型的行为特征，完善模型
根据前述的规则提炼、场景分辨、流程设计对模型进行完善，补充模型中各个概念的行为特征、概念之间的交互活动以及概念本身的状态集合
F) 验证模型对规则、流程以及核心场景的描述的完整性和准确性

• 模型需承担领域内的状态的维护。
• 模型需支撑并维护业务规则，并提供数据一致性保障。

结语
梳理领域的上下文（准确地说是限界上下文），并分析和设计上下文之间的协作关系，属于战略建模，这部分是整体领域建模成功的基础。

另一方面，DDD还提供了很多实用的战术建模工具和模式：聚合、实体、值对象、工厂、仓储、领域服务、领域事件等等。我们可以使用这些工具，来为某个领域（子域）细化模型的设计。最终通过实际的代码将设计沉淀下来（这是整个DDD实践过程的第一个重点）。

但在对所有这些工具很熟悉之前，不要尝试组合过多的工具来设计，宁可方法上存在一定的不完整，但不允许设计的产物因为方法的理解误差导致结果上的偏差。