[译文]Domain Driven Design Reference（一）—— 前言

如果这是第二次看到我的文章，欢迎订阅z哥的公众号（跨界架构师）哦~

每周五11：45 按时送达。当然了，也会时不时加个餐～

本书是Eric Evans对他自己写的《领域驱动设计-软件核心复杂性应对之道》的一本字典式的参考书，可用于快速查找《领域驱动设计》中的诸多概念及其简明解释。

        DDD到目前为止知道的人越来越多了，正巧今天在自己的书单中翻出这本尘封已久的电子版，网上查了下也没有人来翻译，所以近期就准备把这个本书翻译一下，也锻炼下自己蹩脚的英文水平，如有错误欢迎及时指出。>_<|||   内容不多就50多页，我每次按一个章节来发，敬请期待。由于第一章主要是讲一些致谢什么的，这次一起发2章（传送门：[译文]Domain Driven Design Reference（二）—— 让模型起作用）的内容。有想阅读原版的可以私发我邮箱地址，我给你发过来。好下面从”致谢“开始：

致谢

　　自从我的书《Domain-­‐Driven  Design, Tackling  Complexity  in  the  Heart  of  Software》（或者叫“大蓝书”，正如有些人所说的那样） 出版以来已经有10年多的时间了。在这段期间内，书中讨论的基本原理没有太多变化，但是关于我们如何构建软件发生了很大的变化。DDD仍然保持着关联是因为聪明和创新的人们在不断的改变着它。我想要感谢那些人。

　　让我从Greg  Young,  Udi  Dahan和在CQRS、Event  Sourcing上受他们启发的人开始讲。这些是现在DDD系统的主流架构选项。这是本世纪初有限视角的架构中衍生的第一个成功的大发展。

　　从那以后，有许多以DDD更加落地为目标（以及他们的设计者的其它目标）的有趣技术和框架出现，取得了不同程度的成功。包括Qi4J，Naked Objects，Roo等等。这样的尝试即使没有得到广泛的采用，也具有很大的价值。

　　我还是想要感谢那些变革我们的技术生态的人和社区，使得DDD更加的有趣和实用。这些人中大多数对DDD的兴趣很小，但他们的工作使我们受益匪浅。我特别想到NoSQL给我们带来的自由，减少了新编程语言（一些功能）的语法噪声，以及对更轻的技术框架和非侵入性，解耦的类库的不懈努力。10年前的技术复杂而笨重，使得运用DDD十分困难。当然也有不好的新技术，但趋势是好的。 因此，我特别感谢所有为这一趋势做出贡献的人，尽管您可能从未听说过DDD。

接下来，我要感谢那些写了关于DDD的书籍的人。在我之后关于DDD的第一本书来自 Jimmy  Nilsson【1，额外补充一下是这本《领域驱动设计与模式实战 [Applying domain-driven design and patterns]》】。有一本书的话，你仅仅“有一本书”而已。但是有2本的话，你就有了一个主题。接下来，InfoQ发布了《DDD Quickly》，由于其简洁，免费下载以及InfoQ的影响力，让很多人第一时间了解了该主题。这些年过去了，还有许多有价值的博客文章和其它的短文。也有专门的书籍，如《DDD  with  Naked  Objects》【2，额外补充一下找不到文中同名的书，猜测可能是这本《Domain-Driven Design Using Naked Objects》】。另外我特别想要感谢不可缺少的Martin  Fowler，他除了经常提供新兴模式的权威文档还帮助清楚的传达DDD的概念。就在去年，Vaughn Vernon发表了自我以来最有雄心的书，《Implementing Domain-­‐Driven  Design》（有些人似乎称之为“大红书”）。

　　我感到一种绝望，就是我会抛弃许多做出重大贡献的人，我真的为此感到遗憾。让我至少给那些把DDD推到公众视野的人和那些把DDD推到组织安静的角落的人表示谢意。一个软件哲学需要成千上万的拥护者才能产生影响力。

　　虽然这是《DDD Reference》的首印版，单却是我2004年出版的书籍的最初的样子。根据Ralph  Johnson的一个建议，我提取了每个模式的简要总结并在研讨会使用它们，每个模式都由与会者大声朗读，随后进行讨论。我把这些文件用于培训班好几年了。

然后，在我的书出版几年之后，Ward  Cunningham，将他在Repository模式中工作的一部分向几位作者提出，然后我们把我们模式的简短摘要加入到 Creative  Commons【3，一个知识共享组织，参见https://baike.baidu.com/item/creative%20commons/8755425?fr=aladdin】中了。Martin  Fowler和我在出版商Pearson  Education公司的协议下做到了这一点，这就为这种衍生作品开创了可能性。

定义

　　领域（domain）：知识、影响或者作用的一个范围。用户应用一个程序的主题范围是软件的领域。

　　模型（model）：一个抽象的系统，用来描述一个领域的指定的方面，并且可用于解决与该领域有关的问题。

　　通用语言（ubiquitous  language ）：围绕领域模型构建的一种语言，所有团队成员都可以在限定的上下文中使用该软件将团队的所有活动连接起来。

　　上下文（context）：决定一个单词或者句子出现所表示含义的环境。有关模型的生命只能在上下文中被理解。

　　限界上下文（bounded  context）：描述一个特定模型被定义和适用的边界（通常是一个子系统，或一个特定团队的工作）。

模式预览概览

▶作者：Zachary（个人微信号：Zachary-ZF）

微信公众号（首发）：跨界架构师。<-- 点击查阅近期热门文章

如果你是初级程序员，想提升但不知道如何下手。又或者做程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。

如果你是运营，面对不断变化的市场束手无策。又或者想了解主流的运营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思维导图。

定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些深度思考。

扫码加入小圈子