事件风暴划分业务边界
DDD是什么？
领域驱动设计是一种处理高度复杂域的设计方法，试图分离技术实现的复杂性，围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演化等问题。团队应用它可以成功地开发复杂业务软件系统，使系统在演进时任然保持敏捷。
另外一种解读：DDD不是语言，不是框架，不是架构，而是一种思想，一种套路，它可以分离业务复杂度和技术复杂度，DDD也并不是一个新的事物，它是面向对象的拔高，最终目标还是
高内聚，底耦合
DDD主要解决的问题？
-
如何合理的划分业务系统？
这为微服务的划分提供了方法论（微服务的粒度的问题，多大算大，多小又算小，在微服务刚兴起时，很多企业或者架构师对它都没有统一且明确的定义，这里给些examples，e.g：代码行数？职责的划分？披萨原则？组织结构？）界限上下文很好的回答了这个问题，这也是DDD最近几年借微服务的东风，火起来的原因之一(领域驱动设计的提出距今已经十多年，但真正火热起来大约是在2013年微服务架构被提出来之后)。 -
如何保持业务架构和系统架构的一致性？
与传统的系统相比，DDD里面强调领域专家和技术团队的合作，建立统一语言“普通话”， 聚焦在领域，领域逻辑和业务流程上面，使整体团队对同一个业务术语有统一的认识，避免理解的偏差，并将这些“术语”映射到代码中，随着系统的演进变迁。
DDD战略设计？
DDD领域划分?
根据问题域，将问题划分为Core domain，Sub domain， Support subdomain和generic subdomian，大概标准如下：
- 核心域：核心竞争力，核心业务 (需要投入最好的人力和资源)
- 支持子域： 没有，很糟糕; 有，也不足以脱颖而出(可以考虑外包)
- 通用子域：都有的东西, 比如认证, 发短信, 客服系统等(可以考虑购买商业解决方案或者采用开源方案)
DDD领域建模方法？
领域建模的方式很多种，比如四色建模、OOAD还有事件风暴，我们这里只简单聊聊如何使用事件风暴梳理业务流程，建立领域模型，划分边界。
DDD事件风暴四部曲？
- 识别领域事件
事件是对结果进行建模，我们在寻找领域事件时，首先需要明白领域事件具备的几个特征：
- 具有业务意义
- 过去时，e.g: "XX已XX"
- 时序性
事件风暴以过去发生的事件追溯系统的数据和行为，从而进行合适的建模，e.g：
-
识别命令
命令可以理解为不同角色用户在界面上面的操作，比如“添加商品”，“编辑库存”，“提交订单”等； 有些命令可能产生多个事件，可以将他们用箭头联系起来; 在进行这个过程中，我们也需要将角色，通过不同的颜色标示出来 e.g:
命令风暴.png -
寻找聚合
在DDD中，聚合是一组相关的领域对象，其目的是要确保业务规则在边界内的不变性，聚合根具有全局标识，所有对聚合根内对象的修改，都只能通过聚合根进行，聚合帮助我们简化了复杂的对象网络，逐步做到“高内聚，低耦合”。
在识别聚合的时候，我们可以通过对命令和事件的划分找到聚合边界，识别出分布在时间轴上面不同位置的相关命令和事件，e.g：
寻找聚合.png -
边界划分
划分服务的边界，它一定程度上面对应的是“界限上下文”，关于它有一个非常形象的定义：
细胞之所以会存在，是因为细胞膜定义了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜
一个聚合可能是最小颗粒度的界限上下文，同时，我们常合并业务相关性很高的聚合。e.g:
最后在领域划分的时候，需要团队一起对业务达成共识，首先建立统一语言，然后识别领域模型，划分子域和界限上下文，在验证界限上下文的时候，如果你发现有过多的角色在同一个子域或者界限上下文时，就需要注意了，这就是典型的坏味道，需要及时调整的讯号。
DDD与微服务
理想情况下，界限上下文与微服务可以一一对应，在实际项目中，有些调整，比如根据业务的相关度和变化频率，有时候我们会将多个界限上下文进行合并；另外微服务在开发，测试，部署，发布和运维等等时，相比单体应用而言，它面临了所有分布式系统面临的问题，带来了额外的复杂度和开销，所以将微服务粒度拆分过细反而是一种反模式，需要考虑需要解决问题的复杂度，将相对简单的服务合并在一起；在微服务拆分的时候，也要注意：“聚合是服务的最小单元”（一个界限上下文可以包括多个聚合），打破聚合，就很有可能破坏事务一致性和业务约束。
