健康资讯 
DDD经历了三个阶段：首先是Eric Evans的理论原则创建和普及阶段；然后是引入领域事件、事件溯源阶段；最后是微服务架构的提出阶段。
通过事件风暴会议发现领域中的事件，对领域的上下文进行切分，发现其中的聚合。
发现寻找领域或上下文边界才是DDD中最难，也是最需要创造力的地方。边界或有界上下文是DDD专门用于解决复杂性的有力武器，是DDD的核心内容。DDD是专门解决复杂性的方法论。
当需求规模比较大时，需求内部之间可能会发生矛盾，且隐藏深。
使用DDD建模并不是为了将整个系统预先设计出来，而只是让一些有丰富领域知识和逻辑思考能力的人通过头脑风暴发现系统的复杂核心所在。
复杂性无法消除，问题空间的复杂性是天然存在的。
理解复杂性有自己的一套分析方法，如分门别类，逐步、有层次地分解。
DDD关注的重点就是如何将复杂的问题空间通过逻辑分析解析出来，从原来的混乱无序变得有条理、有层次，这样经过梳理的复杂性才是DDD需要的结果。
分析结果变得有层次，相互隔离、松耦合，就能分派不同的团队专门处理各个问题的子域或有界上下文，分而治之。
DDD事件风暴（Event Storming）建模倡导将脑袋大开的产品经理和严谨求证的程序员召集在一起进行头脑风暴。大胆设想和小心求证在这里得到了融合，通过事件风暴会议，程序员能够更加理解业务领域知识，产品经理会发现自身的逻辑矛盾之处，通过反复迭代，创意开始变成可实施的产品。关键是，每个人对复杂性的认识逐渐一致，复杂性被专门隔离出来，可以先从容易的地方下手，逐步逼近复杂性。随着时间推移，每个参与者都会朝着目标更进一步，复杂性被肢解，由不同的团队专门负责不同的有界上下文或微服务，同时在敏捷实施过程中，不断调整人员。领域的边界划分不断演绎，只要发现复杂性凝聚的地方，就划定为有界上下文，割裂它与其他系统的关系，并派出精兵强将专门对付。
DDD是复杂问题的解决之道。
DDD解决问题的方式继承了多年的面向对象分析设计方法学，同时吸收了函数式编程的优点。
DDD实施中最大的副作用是可变状态的管理。
DDD聚合根代表一个有界上下文的复杂核心概念，其复杂性来自聚合根实体的状态是经常可变的，如订单的状态从支付变为发货，这种变化决定了整个系统的成败——如果一个订单没有支付，但是商家发货了，这样是不合理的。
DDD通过边界划分和状态封装固定了复杂的可变状态，可以结合函数式编程消除可变状态产生的全局影响。采取事件溯源等方式，直接记录发生的领域事件，并不改变状态，所有需要订单当前状态的有界上下文自己通过遍历这些领域事件来合成当前状态，这样的状态既是实时的又是准确的，也是可以追溯的。
DDD解决了传统面向对象分析和设计的割裂状态。面向对象分析的结果会被设计细节干扰，导致严重偏离分析方向，DDD是一种“一竿子插到底”的方法，分析的结果必须经过设计细节验证。
事件风暴首先提取领域中发生的事件，从非常细节的动作入手来分析需求，而传统的面向对象分析方法则是主语名词法，首先寻找领域中有哪些实体名词，这种分析方法其实受到了ER数据模型的影响。事件风暴从动词事件入手，这些事件正是日后需要实现的功能激发的。事件离需求功能更接近，对领域事件进行分门别类，可以发现有界上下文和聚合。使用领域事件替代可变状态，可以实现有界上下文之间重要的状态传递，领域事件是就是DDD一竿子插到底的那根“竿子”。
键是要掌握DDD分析方法的核心：从细节动词入手发现有界上下文和聚合，以逻辑一致性为边界划分依据，对动作实现分门别类地划分。
DDD非常强调语言表达，DDD是一种关于自然语言符号分析的方法学，它倡导的统一语言、无所不在的语言，正是从语言分析入手去发现上下文语境的。同一个领域模型在不同上下文语境中是不同的，因此需要分别建模，如客户管理上下文中客户无疑是主语，是主导者，而在订单上下文中，客户只是订单这个主语的附加定语或组成信息而已。
DDD继承了传统面向对象分析设计方法，结合了函数式编程风格，同时照顾了ER数据模型的设计，是过去主流方法学的集大成者，它通过划分边界、纲举目张、分而治之等分析方法直面分解复杂问题，而不是隐藏回避复杂问题。
DDD遵从单一职责、少即是多、大道至简等设计原则，吸收了各种新的分析方法和思想，不断努力降低技术债务，提升软件质量，提高软件的可维护性和可拓展性。
模块之间松耦合，特别是核心部分得到隔离，核心部分又通过聚合凝聚在一起，很多核心功能通过聚合功能优化即可，摆脱了对数据库的依赖，数据库表字段的增加和修改几乎完全避免了，也不会对原始数据进行各种转换。
使用Java在内存中计算排序或做各种处理，包括业务流程的变化都不影响数据表结构，通过新增数据表结构来实现新业务数据的保存，不去修改原有结构，通过Java的聚合模型将新旧数据表结构凝聚在一起。
