领域驱动设计(Domain-Drive Design)的真正附加价值
DDD的目的——应对软件核心复杂性。
DDD的核心——消化特定业务领域的知识并创建忠实反映它的软件模型
是什么让DDD如此强大却又如此容易出错？——是上下文。
业务领域是一个公司开展自身业务的方式：组织、流程、实践、员工和语言。业务领域存在于一个上下文里。即使非常相似的业务也可能存在于不同的上下文里。
如果你消化了足够的知识并能忠实地建模，那么DDD用起来既简单又强大。如果你缺乏知识或者无法把你的知识转变成符合业务领域的模型，那么DDD用起来会很痛苦。
怎么使用DDD
使用DDD的关键——理解它的真实价值和学习使用它的技术。
容易犯的错误：
- 仅仅因为DDD很酷就随大流
- 认为现有系统仅比简单的CRUD复杂一点就坚决忽略DDD
DDD的真正附加价值——使用分析部分标识出绑定业务上下文。接着，有选择性地利用策略设计实现任何绑定上下文
DDD包含两个部分。有一个部分是必须的，另一个部分有时候可以放心地忽略。
DDD的分析部分提供一个方案，根据绑定上下文表达业务领域的顶层架构。此外，DDD的策略部分为标识出来的绑定上下文定义支撑架构。
使用DDD——分析部分
DDD的分析部分包含两个相互关联的元素：统一语言和绑定上下文。
统一语言是项目各方共同使用的词汇表，会在项目里通过口头和书面交流的形式大量使用。作为一名架构师，你通常会一边学习领域知识，一边添加动词和名词等词汇。这是着手创建词汇表的常见方案。更一般的情况是，你也应该仔细检查你在需求里找到的副词短语，因为它们可能提供大量领域内容，如事件、流程和流程的触发条件。
统一语言对于你最终要写的类的名称和结构也会有所启示。统一语言改善和加速需求的确认，简化各方之间的沟通，从而避免误会、臆断、假设以及不同行话之间切换时产生的拙劣翻译。
一开始只有一个统一语言和一个需要了解和建模的业务领域。随着你深入了解需求和探索领域，你可能会发现名词和动词之间存在某种重合，它们在领域的不同区域有着不同的含义。这会引导你把原本的领域分成多个子领域。
绑定上下文是DDD用来指代独立领域区域的术语，这些区域都有自己的统一语言。从另一个角度来说，新的绑定上下文会在统一语言发生改变时产生。任何业务领域都山上下文组成，而每个上下文由逻辑轮廓（logical contour）塑造。软件架构师的首要职责是识别出领域里的业务上下文并定义它们的逻辑轮廓。
上下文映射通常用来指代DDD的分析部分。上下文映射是一项通用技术，可以在几乎任何软件场景里使用。上下文映射从软件架构师的角度构建领域的顶层视图。它展示子领域和它们的关系，帮你做出策略决定。
使用DDD——策略部分
与上下文映射搭配使用的是策略模型设计。一旦你识别出各种绑定上下文，你的下一个任务就是为确定每个确定最佳架构。DDD提供的推荐架构是分层架构和领域模型。
DDD推荐基于领域模型设计的分层架构。领域模型通常是一个对象模型，但它也可以是其他东西，比如说，一组函数。数据的持久化也取决于模型的结构。
领域模型是对象模型
领域模型是由一种特别的对象模型（也被称为领域模型或实体模型）和一组领域服务类组成的。
如果这个模型是一组对象，它可能需要O/RM工具。
基于函数的领域模型
如果这个模型是基于函数的，它甚至可能基于从惯用的包装组件调用的存储过程。
注意：根据Evans给出的原定义，DDD对于开发者来说是面向对象设计的自然进化。OOD的第一原则建议寻找“相关类"。DDD建议你仔细地建模领域一一通过寻找相关类仔细地建模领域。
策略模型设计阶段的任务包括评估各种架构方案以及为每个绑定上下文选择架构。在分层架构之外，领域模型通常还有其他方案，如简单的CRUD、CMS（当绑定上下文是一个网站时），或者更加复杂的东西，如事件源。
是否选择DDD要考虑的元素
以下方面的大前提是——基于估算软件的使用期限。
快速应用程序
假设你要写一个短期的一次性的应用程序，比如说一个调查Web应用程序，或者一些类似的页面，收集用于分析的原始数据。你知道预期的使用期非常短，而且在需要的数据收集到之后这个应用就会被直接丢弃。
真的值得耗费更多时间只为让它工作？可以使用最快的CRUD方案，不管是WebForms、Silverlight还是简单的HTML。
需要考虑：快速应用程序可能只是一个更大、更复杂的领域的其中一个绑定上下文，作为一个资深架构师，你需要对它进行映射。
前端网站
负责的项目需要一个web前端。它有一个非常复杂的后端，必须考虑大量业务规则，也必须协调很多外部web服务，但到了最后这个前端是一堆只读页面，没有表单或者只有少数表单。你得到的最重要需求是：“它必须非常酷，非常吸引人。”
webForms可以直接排除，因为服务器控件带来太多限制。ASP.NETMVC是一个更好的选择，因为它允许完全控制HTML，也能有效地使用css。你真的应该从头开始创建ASRNETMVC解决方案吗？CMS不是一个更快而且同样酷的解决方案吗？
一个软件架构师可以识别出复杂性，他看到但不会增加任何不必要的复杂性。你可能知道扩展CMS的插件，如WordPress，可以完成你想做的大多数事情。通过一个很酷的主题和一堆插件，包括自定义插件，来完成这个工作并非不靠谱。再强调一次，关键是机会和技能，关键是所针对的上下文。
其他类型的应用程序
“让代码工作”是一个不错的格言如果你不需要在代码完成并工作之后碰它。
不管客户怎么说，也不管当前计划是什么，任何软件无需后续更改的原因只有一个：它将被弃用。如果软件不会在几个月后弃用，作为一名架构师，你最好考虑一个周全的方案，而非使用快餐代码。
注意：温馨提示，无独有偶，维护既是OOD的设计目标，也是ISO9126提到的一类必要条件。