领域驱动设计（Domain-Driven Design，简称 DDD）是一个站在整个软件项目全局维度进行规划设计的系统理论和方法，而洋葱架构，六边形架构等是属于具体的软件工程管理模型。
采用DDD的目标是为了确保复杂软件系统的整体设计是稳健的，可扩展的。
在DDD中有许多名词和概念，比如：领域专家，战略设计，战术设计，通用语言，限界上下文，上下文映射图，领域，核心域，支撑域，子域，聚合，领域事件，领域服务，实体，值对象等等。
DDD首先并不是关于技术的，而是关于讨论、聆听、理解、发现和业务价值 的.而这些都是为了将知识集中起来。
通用语言和限界上下文同时构成了DDD的 两大支桂，并且它们是相辅相成的。
通用语言是团队共亨的语言。领域专家和开发者使用相同的通用语言进行交流。
通用语言是团队自己创建的公用语言，团队中同时包含领域专家和软件开发人员。
DDD强调将精力花在对业务最有价值的东西上。我们并不过度建模，而是关注业务的核心城。有些模型是用来支撑核心域的，它们同样是重要的。但是，这些起支撑作用的模型在优先级上没有核心域高。
DDD并不是画模型图，而是将领域专家的思维模型转化成 有用的业务模型。DD不是创建一个真实世界的模型，而是模仿现实。
DDD买用的是一种“敏捷的”方式进行软件开发的。
在DDD设计的中一些原则（有可能这些原则跟其他设计模型中的原则是冲突的，比如OOP编程中的贫血模型）：
- 请把业务逻辑放在领域模型之中，不然就要忍受贫血领域模型带来的问题。
当使用DDD时，我们的任务是深入学习业务如何运作，然后基于学习的范围建立软件模型。
这实际上是一个学习、试验、质疑、再学习和重建模型的过程。我们要从大量学到的内容中研磨和提炼知识，并创造出能有效满足组织战略需要的设计。
几个疑问？
1.在什么类型的软件项目中应该采用DDD设计？是针对完全陌生领域的软件项目吗？
2.在什么时候开始DDD设计？产品设计之初？还是在产品设计之后？
可借鉴经验
- 中小团队落地DDD，无需全量照搬所有概念，可先从「包结构按领域划分 + 核心聚合根建模 + 轻量领域事件」入手，低成本落地，避免过度设计。
- 传统MVC架构的项目，可通过「分层改造 + 核心领域建模」实现轻量DDD落地，无需重构整个项目，渐进式演进，降低重构成本。
可落地的通用实践经验
1.先做领域建模，再做微服务拆分：DDD 的核心是「领域建模」，微服务只是落地形式，切勿为了拆微服务而拆，先通过领域建模明确限界上下文，再将「一个限界上下文作为一个微服务」（或多个小上下文合并为一个微服务），避免微服务拆分过细 / 过粗；
2.业务人员必须深度参与领域建模：DDD 是「业务驱动的设计方法」，领域模型的准确性取决于对业务的理解，建模时必须让产品经理、业务专家、开发人员一起参与，避免「技术人员闭门造车」，模型与业务脱节；
3.轻量落地，拒绝过度设计：除了金融、电商核心业务等超复杂场景，大部分项目无需全量实现 DDD 所有概念（如事件溯源、CQRS、值对象的严格不可变），可根据业务复杂度做减法，核心是「解决业务问题」，而非照搬概念；
4.聚合根设计遵循「高内聚、低耦合」：聚合根的边界是「业务上的一致性边界」，如订单和订单项必须在一个聚合根中（业务上需要强一致），订单和物流轨迹则无需在一个聚合根中（业务上可最终一致）；聚合根内的操作通过本地事务保证强一致，聚合根间通过领域事件实现最终一致；
5.领域层是核心，不依赖任何外部层：领域层（聚合根、领域服务、值对象）必须是纯业务层，不依赖框架（如 Spring）、不依赖数据库、不依赖前端，仅定义业务规则和领域模型，这样领域模型才能独立演进，不受技术栈变化的影响；
6.渐进式演进，不追求一步到位：传统单体项目向 DDD 演进，切勿一次性重构整个项目，可先从核心业务域（如订单、库存）开始落地 DDD，验证效果后，再逐步向其他业务域扩展，降低重构风险和成本。
【参考】
DDD 领域驱动设计指南
领域驱动设计中文资料
在什么类型的项目应用DDD，DDD设计案例，DDD设计与产品设计的先后关系
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达，在下面评论区告诉我^_^^_^
