如何对业务流程进行 DDD 领域设计分析 DDD 包含什么在系统架构落地体现在哪些方面
曾天文
如何对业务流程进行DDD领域设计分析，DDD包含什么，在系统架构落地体现在哪些方面？
原创 曾天文 爱记不记的记忆碎片
一
问题
如何对业务流程进行DDD领域设计分析，DDD包含什么，在系统架构落地体现在哪些方面？
二
答案
DDD的概念
DDD是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂性并围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演进的问题。
DDD不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮助设计出清晰的领域和应用边界，可以很容易地实现架构演进。
DDD分析的核心
DDD分析的核心在于4个方面： 统一语言，限界上下文，领域模型，事件风暴 。
1. 统一语言
统一语言关键在概念思维，既定后共同遵循成习惯，达成有效沟通。
2. 限界上下文
限界上下文是一个用来界定领域模型的显性边界，它定义了一个特定的领域或子域内部的语言、规则和概念。
根据 业务相关性、耦合的强弱程度、分离的关注点对这些活动进行归类 ，找到不同类别之间存在的边界，这就是限界上下文的含义。上下文(Context)是业务目标，限界(Bounded)则是保护和隔离上下文的边界，避免业务目标的不单一而带来的混乱与概念的不一致。主要解决的是区分出边界，及边界内的领域模型的联系，边界外上下文间的联系，最后自然得出业务领域的范围。
3. 领域模型
领域模型是在单个限界上下文中构建和细化，抽象出来的，并结合事件风暴可以分析设计出能够体现领域逻辑的软件组件。
4. 事件风暴
任何的业务都会以 数据/对象模型 的形式留下足迹。我们对于 数据/模型的追溯可以通过对事件 的追溯来完成。当把这些事件按照时间顺序排列起来，几乎可以清晰的推测出在过往的一段时间内到底发生了深数据变化。
领域模型与领域事件，是可以互为分析追溯，既可以通过模型得知模型周边会发生的领域事件逻辑，也可以通过事件追溯抽象出模型本身。
DDD对于架构落地的作用
DDD是架构分析方法，微服务是一种系统架构，DDD目的是做出合理的微服务架构，具体落地是体现在微服务的划分上，以及在划分微服务后，基于单个领域服务的DDD代码子域模块的划分。
DDD避免了落地部署时的2种极端
（1）系统数据负载量大，把所有业务领域模型，事件都合在一个微服务，无法分布式扩展分担性能负载，导致业务可用性低；
（2）把1-2个领域模型就划分为1个微服务，导致跨服务调用，数据一致性无法控制，导致业务容错低。
END作者丨曾天文
审核丨邓金边
编辑丨王 锐
