领域驱动设计理解&总结 这篇文章主要是通读《实现领域驱动设计》之后自己的理解和总结（同时也参照一些博文的分析来加深自己的理解）；
红字部分是有疑问或是自定义内容，虽然有自己的理解，但依然感觉较为抽象，后续会通过实践来理解其中的精妙之处。
领域驱动设计指引
领域驱动设计 作为一种软件开发方法，提供了战略上（思考方式） 和 战术上（落地方式） 的建模工具来帮助我们 设计高质量的软件模型；
领域驱动设计 不是关于技术的，而是关于讨论、聆听、理解、发现业务价值 的，目的是将 知识 集中起来，形成 通用语言（Ubiquitous Language）；
在 领域驱动设计 中，技术也重要，但更重要的是要掌握 领域建模 中更高层次的概念；
领域建模在领域中构建模型，什么是 领域模型？
关于 某个特定业务领域的软件模型。通常，领域模型通过 对象模型 来实现，这些对象包含了数据和行为，并且表达了准确的业务含义。
为什么要使用DDDVaughn Vernon（沃恩.弗农） 在他的书里（《实现领域驱动设计》）阐述了很多，总结3点：
领域专家、开发者、业务人员等都掌握同样的软件知识，大家都使用相同的语言进行交流，每个人互相理解彼此在说什么；
设计就是代码，代码就是设计，软件能够表达大家所理解的意思；
DDD持续关注业务，会产生一些业务价值
获得一个有用的 领域模型；
业务得到更准确的 定义和理解；
领域专家可以为领域设计做出贡献；
更好的用户体验（软件本身容易上手，减少培训，提高效率）
清晰的模型边界
良好的企业架构
敏捷、迭代式和持续建模
使用 战略和战术工具
DDD推进过程中存在的挑战
创建通用语言（所有人达成一致的某个业务术语的统一认知）消耗额外的时间和精力
持续的将领域专家引入项目
改变开发者 对领域的思考方式
如何使用DDDDDD 提供了战略上 和 战术上 的建模工具来帮助我们 设计高质量的软件模型，战略设计 侧重于高层次、宏观上去划分和集成限界上下文，而 战术设计 则关注更具体使用建模工具来细化上下文。
战略上
限界上下文（Bounded Context） 为团队创建一个建模边界；
成员在边界内部为特定的 业务领域 创建 解决方案；
单个限界上下文中团队成员共享一套 通用语言（Ubiquitous Language）；
不同团队各自负责一个限界上下文，可以使用 上下文映射图 对限界上下文进行 界分和集成；
战术上
实体（Entity）
值对象（Value Object）
聚合（Aggregate）
领域服务（Domain Service）
领域事件（Domain Event）
资源库（Repository）
下边我针对 战略和战术 两个方面进行讲解
DDD之战略 领域广义上讲：领域 是一个组织所做的事情以及其中所包含的一切（为某个组织开发软件时，你面对的就是这个组织的 领域）。
软件开发中：领域 既可以表示 整个业务系统，也可以表示系统中的 核心域 或者 支撑子域。
在DDD中：领域 被划分为若干 子域，领域模型 在 限界上下文 中完成开发。
领域 包括下边三种 子域：
核心域（业务成功的主要促成因素，是企业的核心竞争力，应该给予最高的优先级、最资深的领域专家和最优秀的开发团队，实施DDD的过程中主要关注于 核心域）；
支撑子域（不是核心，对应业务的 某些重要方面，有时我们会创建或者购买某个支撑子域）；
通用子域（不是核心，但被整个业务系统所使用）；
现实世界中的领域现实世界中的领域包括 问题空间（Problem Space）和 解决方案空间（Solution Space）:
问题空间：是核心域和其他子域的组合，思考的是 业务面临的挑战
解决方案空间：一组特定的 软件模型，包括一个或多个限界上下文，思考的是如何实现软件（限界上下文 即是一个 特定的解决方案，通过软件的方式实现解决方案）以 解决这些业务挑战
限界上下文
一个 显式的边界（主要是一个语义上的边界），领域模型便存在于这个边界之内；每一个模型概念（包括它的属性和操作）在边界之内都具有特殊的含义；
一个 给定的业务领域 会包含多个限界上下文，想与一个限界上下文沟通，则需要通过显示边界进行通信；系统通过确定的限界上下文来进行解耦，而每一个上下文内部紧密组织，职责明确，具有较高的内聚性；