今天跟随内心的声音，去参加DDD，因为它是今年我们想要尝试的一个点，所以希望借助这一下午的时间对它有更深一步的了解。没有学习的太深入，但有几个点，值得一提:
- 再完美的架构，也不能解决所有问题，因为我们需要考虑时间的维度。架构一开始都是完美的，但随着时间的推移，就会腐化。我们无法预测和控制业务往哪个方向去走，要在时间维度上去考虑架构持续演进，就是一种进化的思路，我们唯一可以控制的是环境的约束条件，知道如何去伪存真。
- 领域建模时，一般有两个领域，核心域和支撑域。重点需要关注核心域，因为它是我们的核心竞争力所在。比如，京东的物流系统。
- 当今时代的“权利转移”，一切由客户说了算。因此，领域建模的核心是找到用户，围绕用户。
- 领域建模的三个层级:战略设计，战术设计和代码设计。越往前越重要。战略设计包括，用统一语言，各种角色的协作方式。战术设计即实现建模，代码设计，就是代码层面的结构设计。
- 传统的架构设计，一开始关注在系统架构和代码架构。二者设计好了以后，业务架构是去做适应。而DDD中，一开始是将业务架构和系统架构绑定在一起，然后才是代码架构。一切从业务出发，也就是从用户的需要出发去构建我们的架构。
总结来说，三个关键点:
- 业务分析的过程，理清用户的诉求，需求的范围，有助于简化模型。
- 把握核心业务问题，有助于确定需求和模型的边界。
- 业务全景分析，可以找到合适粒度的服务。
协作对业务领域的分析，自然驱动出上下文地图
- 用户访谈，梳理用户目标
- 了解当前业务流程
- 找出核心业务问题
- 勾勒未来业务流程
- 识别出子领域
- 对子领域，识别核心领域对象
- 做出Context Map
- 检验功能地图和Context Map是否对应
图片发自简书App
