DDD的核心思想封装，从业务角度进行领域的划分、聚合的隔离，即业务的封装，聚合是业务的最小单元，具有原子性特征，聚合之间与子领域之间一样，通过协作方式（如，消息）来实现业务，以此来实现高内聚、低耦合的设计原则（P.S 只有业务内聚才能实现真正的高内聚）。
封装即是隔离，隔离与外部的交互，好处当然不言而喻——低耦合，使重构变得安全、容易，随时拆分为独立服务，等等。
利与弊总是并存的。DDD的好处在于，很好的解决了业务人员与技术人员的沟通问题和高内聚低耦合的开发和架构演进问题；DDD的弊在于，将数据不一致的影响面进一步放大，由微服务级别放大到微服务内的聚合级别。
那么，在DDD的落地过程中，我们需要关注哪些问题呢？
一、团队
首当其冲的就是团队，团队的协作模式，在DDD中，领域模型与语言是由团队（业务人员、技术人员）一起建立的，它是一种环形协作模式，不再是链式协作模式。
二、开发实现
1. 领域/业务逻辑的隔离与演进
业务逻辑是核心，除了受到业务变化的影响外，不应受到任何其他的影响，如，存储介质。
2. 聚合与领域事件的原子性
领域事件由聚合产生，属于聚合的一部分，落地时需确保聚合状态的持久与领域事件发布的原子性，即，都成功或都失败，否则将导致数据一致性问题。
3. 聚合之间的数据一致性
聚合是原子性的，聚合之间是最终一致性，除了达到数据一致性外，数据一致性的时间窗口也非常重要。
4. 聚合的持久
聚合的持久与聚合的结构无关，即，可根据查询性能等需要进行任意结构的存储。
5. 聚合的并发问题
同一时刻对同一聚合的修改，需确保聚合的数据安全性。
