DDD是解决 软件复杂度 中的业务复杂度问题的，是微服务划分最好的实践。
业务复杂度主要表现在：客户的业务需求，比如业务流程多，参与者多等，而且这种复杂度往往会随着需求规模的增大而指数级增大。
在分析软件复杂度之前，先要了解业务价值所在。即DDD的领域与核心域这里所说的关注业务核心域。我们是要聚焦解决业务核心域的软件复杂度的。
我们大部分需求是横跨多个团队，需求传递低效，需要反复沟通，方案产出效率低，而统一语言（DDD中为什么强调统一语言？）使得产研在业务概念、理解等方面达成一致，降低沟通和理解成本。
对于复杂的业务领域，领域可能需要多级拆分后才能开始领域建模。领域拆分为子域，甚至子域还需要进一步拆分。
小的问题域内，领域建模过程相对简单，直接采用DDD的事件风暴的方法构建领域模型就可以了。
事件风暴分四个阶段：
-
产品愿景阶段，对产品顶层价值的设计，使产品目标用户、核心价值、差异化竞争点等信息达成一致，避免产品偏离方向。
-
业务场景分析，从用户视角出发，根据业务流程或用户旅程，采用用例和场景分析，探索领域中的典型场景，找出领域事件、实体（理解DDD中的实体、值对象）和命令等领域对象，支撑领域建模。
-
领域建模，使用聚合把关联性强的业务概念划分在同一个限界上下文（理解DDD中的限界上下文-没有二义性），并限定聚合和聚合之间只能通过聚合根来访问，建立领域模型以及模型之间的依赖。
-
微服务拆分，我们可以用限界上下文可以作为粗粒度的微服务边界，但落地时往往不得不考虑更多其他因素，比如弹性边界、安全需求、软件包大小、团队沟通效率、技术异构等等。从被挑战点看微服务适用场景这篇文章给出了服务负责人数、人员能力、组织认可对微服务划分的限制。
整个拆分和事件风暴很难做到一次全面到位，我们需要按照可演进架构的思想去不断迭代完善。
总结
我们什么时候需要使用DDD呢？业务复杂且需要长期维护的时候。
为了避免走弯路，领域设计时需要依次做愿景分析、业务分析、领域建模、服务拆分，从宏观上保障方向的正确性。
