表象：
规模与结构 导致 理解力障碍
变化 导致 预测能力问题
根因：
需求
DDD关注的焦点 在于 领域 以及 领域逻辑
原因： 软件系统的本质： 给客户提供具有业务价值的领域功能
需求分为
业务需求：业务复杂度
技术需求：技术复杂度
面对一个相对复杂的软件系统时，面临的问题：
-
问题域过于庞大而复杂，使得从问题域中寻求解决方案的挑战增加，该问题与软件系统的规模有关。
-
开发人员将业务逻辑的复杂度与技术实现的复杂度混淆在一起，该问题与软件系统的结构有关。
-
随着需求的增长和变化，无法控制业务复杂度和技术复杂度，该问题与软件系统的变化有关。
DDD的应对措施：
1 隔离业务复杂度 与 技术复杂度
首要任务 确定业务逻辑与技术实现的边界，从而隔离各自的复杂度
电商的领域逻辑：
订单业务关注： 验证订单有效性、计算订单总额、提交和审核订单的流程等
技术关注点：从实现层面保障这些业务能够正确地完成，包括确保分布式系统之间的数据一致性，确保服务之间通信的正确性等。
业务逻辑并不关心技术是如何实现
应该保证业务规则与技术实现是正交的
DDD通过分层架构与六边形架构来确保业务逻辑与技术实现的隔离
分层架构
遵循了“关注点分离”原则 ：
业务逻辑的关注点放到领域层
支撑业务逻辑的技术实现放到基础设施层
应用层：
1作为业务逻辑的外观（Facade），暴露了能够体现业务用例的应用服务接口
2业务逻辑与技术实现的粘合剂，实现二者之间的协作
如果我们在领域层或应用层抽象了技术实现的接口，再通过依赖注入将控制的方向倒转，业务内核就会变得更加的稳定，不会因为技术选型或其他决策的变化而导致领域代码的修改。
在领域层建立资源库（Repository）的抽象，它的实现则被放在基础设施层，然后采用依赖注入在运行时为业务逻辑注入具体的资源库实现。那么，对于处于内核之外的 Repositories 模块而言，即使选择从 MyBatis 迁移到 Sprint Data，领域代码都不会受到牵连
（只对repository的实现逻辑进行了改变）
垂直划分：
面相垂直业务切割，将一个庞大的软件系统划分为松散耦合的多个小系统组合
针对庞大复杂度问题域，限界上下文采用分治思想 对问题域进行分解，控制了问题域的规模，进而控制了整个系统的规模
规模减小 业务与技术复杂度均显著的降低，更有利于对领域分析建模
利用限界上下文 将 大系统拆分为小系统后 再利用 分层架构与六边形架构思想 对小系统进行逻辑分层
分层目的：业务逻辑与技术实现相互隔离（隔离业务复杂度与技术复杂度）
