领域驱动设计参考

领域驱动设计是一种解决跨学科交流问题的软件工程方法：由于开发人员和专业人员使用不同的术语，因此存在相互理解问题。

这首先是业务语言问题（不是编程语言），DDD通过为开发人员和专业人员提供一套用于理解的规则以及因此基础领域的通用模型来帮助弥合这一障碍。

Eric Evans最初创造了DDD这个词，他在 这个站点 专门提供一个 DDD参考PDF ，理解DDD的条目通常是困难的，因为DDD术语本身首先是难以理解和有点混乱的，补救的办法是使用好的参考。 本栏目系列文章是对这个参考书的翻译，以原文为准，仅仅供参考。

前言

自从我的书籍《领域驱动设计，解决软件核心的复杂性》（或一些人称之为“大蓝皮书”）出版以来，已经有十多年了。在那十年里，书中讨论的基本原理并没有改变太多，但是我们如何构建软件却发生了很大的变化。DDD一直保持着与现实的相关性，因为聪明和创新的人不断地动摇过去的事情，我要感谢那些创新者。

让我从Greg Young、Udi Dahan和他们所激励的人们开始，首先是为CQR和EventSourcing，这些现在是DDD系统体系结构的主流选择。这是从世纪之交继承下来的狭隘架构观的第一次成功的大转变。

从那时起，已经有几个有趣的技术和框架，它们的目标是使DDD在实现中更加具体（包括其设计人员的其他目标），并取得不同程度的成功。这些包括Qi4J, Naked Objects, Roo和其他。这些实验即使没有得到广泛的应用，也有很大的价值。

我还要感谢近年来以使DDD更有趣和更实用的方式革命了我们的技术生态系统的人们和社区。这些人中的大多数对DDD的兴趣微乎其微，但他们的工作使我们受益匪浅。我特别想到的是NoSQL给我们带来的自由，新编程语言（某些函数）的语法噪音降低，以及对更轻的技术框架和非侵入性、分离的库的不懈驱动。十年前的技术复杂而沉重，使得DDD更加困难。当然，也有不好的新技术，但趋势是好的。所以我特别感谢所有促成这一趋势的人，尽管你可能从未听说过DDD。

接下来，我要感谢那些写过DDD书籍的人。关于DDD的第一本书是吉米·尼尔森写的。有了第一本书，你就又有了一本书，有了两本书，你就有了一个话题。接下来，InfoQ很快发布了DDD，由于它的简洁性、作为免费下载的可用性以及InfoQ的广泛性，这让很多人第一次体验到了这个主题。年复一年，有许多有价值的博客文章和其他简短的形式的作品。还有一些专门的书籍，如DDD和Naked Objects。我特别要感谢不可或缺的马丁·福勒，他帮助清晰地传达了DDD的概念，并经常提供新模式的权威文档。就在去年，沃恩·弗农出版了自我个人以来最雄心勃勃的一本书: "实现领域驱动的设计"（有些人似乎称之为“大红皮书”）。

我感到一种绝望，因为我不可避免地会遗漏许多做出重大贡献的人，对此我深表歉意。我至少要对那些将DDD推向公众视野的人和那些将DDD推向组织安静角落的人，表示衷心的感谢。软件哲学需要数千个拥护者才能产生任何影响。

虽然这是DDD参考的第一个印刷版，但最早的形式实际上早于我2004年出版的书。在拉尔夫·约翰逊的建议下，我提取了每种模式的简要摘要，并在研讨会上使用，每种模式都由与会者朗读，然后进行讨论。我在培训班上用了这些文件好几年了。

然后，在我的书出版几年后，沃德·坎宁安，作为他在模式存储库的工作的一部分，向一些作者建议，我们把模式的简短摘要放入创造性的共享空间。马丁·福勒和我，在我们出版商皮尔逊教育公司的同意下，就这样做了，这为衍生作品打开了可能，比如这本书。

Thank you all.

Eric Evans, June 2014

定义概括

领域Domain ：

知识、影响或活动的范围，用户应用程序的主题区域（业务区域）是软件的领域。

模型model：

描述一个领域的特定方面的抽象系统，可以用来解决与该域相关的问题。

无处不在的语言ubiquitous language：

一种围绕领域模型构建的语言，由所有团队成员在有界的上下文中使用，以将团队的所有活动与软件连接起来。

语境上下文context：

一个词或语句出现在某种环境背景中，而这个背景决定了其含义（语义，同一个词语用在不同上下文意思就不同，双关语等由此而来。）。有关模型的表达只能在一个上下文中理解。

有界上下文bounded context：

定义和适用特定模型的边界描述（通常是子系统或某个团队的工作项目）。

第一章：让模型发挥作用

第二章：模型驱动设计MDA的构建模块

#DDD #业务分析