领域驱动设计实现之路

　　2004年，当Eric Evans的那本《领域驱动设计——软件焦点庞大性应对之道》（后文简称《领域驱动设计》）出书时，我还在念高中，接触到领域驱动设计（DDD）已经是8年后的事情了。那时，我正计划在软件开发之路上更进一步，经同事先容，我最先接触DDD。

　　我想，多数有履历的程序开发者都应该听说过DDD，而且实验过将其应用在自己的项目中。不知你是否遇到过这样的场景：你建立了一个资源库（Repository），但一段时间之后发现这个资源库和传统的DAO越来越像了，你最先反思自己的实现方式是准确的吗？或者，你建立了一个聚合，然后发现这个聚合是云云的重大，它为什么引用了云云多的工具，岂非又是我做错了吗？

　　实在你并不孑立，我信赖多数同仁都曾遇到过相似的问题。前不久，我一个同事给我展示了他在2007年买的那本已经被他韦编三绝过的《领域驱动设计》，他告诉我，读过好几遍后，他依然不知道怎样将DDD付诸实践。Eric那本书虽然是好，无能否认，可是我们程序员总希望看到一些现实的例子能够切实将DDD落地以指导我们的一样平常开发。

　　于是，在Eric的书出书快要10年之后，我们有了《实现领域驱动设计》，作为该书的译者，我有幸通读了本书，受益匪浅，获得的结论是：好的软件就应该是DDD的。

　　就像在微电子领域有知识产权核（Intellectual Property）一样，DDD将一个软件系统的焦点营业功效集中在一个焦点域内里，其中包罗了实体、值工具、领域服务、资源库和聚合等观点。在此基础上，DDD提出了一套完整的支持这样的焦点领域的基础设施。此时，DDD已经不再是“面向工具进阶”那么简朴了，而是演酿成了一个系统工程。

　　所谓领域，即是一个组织的营业开展方式，营业价值便体现在其中。恒久以来，我们程序员都是很好的手艺型思索者，我们总是善于从手艺的角度来解决项目问题。可是，一个软件系统是否真正可用是通过它所提供的营业价值体现出来的。因此，与其天天钻在那些永远也学不完的手艺中，何不将我们的关注点向软件系统所提供的营业价值偏向思索思索，这也正是DDD所试图解决的问题。

　　在DDD中，代码就是设计自己，你不再需要那些繁文缛节的而且永远也无法获得实时更新的设计文档。编码者与领域专家再也不需要翻译才气明白对方所表达的意思。

　　DDD有战略设计和战术设计之分。战略设计主要从高层“俯视”我们的软件系统，资助我们精准地划分领域以及处置惩罚各个领域之间的关系；而战术设计则从手艺实现的层面教会我们怎样详细地实行DDD。

　　DDD之战略设计

　　需要指出的是，DDD绝非一套单纯的手艺工具集，可是我所看到的许多程序员却简直是这么以为的，而且也是怀揣着这样的想法来使用DDD的。过于拘泥于手艺上的实现将导致DDD-Lite。简朴来讲，DDD-Lite将导致劣质的领域工具，由于我们忽略了DDD战略建模所带来的利益。

　　DDD的战略设计主要包罗领域/子域、通用语言、限界上下文和架构气势派头等观点。

　　领域和子域（Domain/Subdomain）

　　既然是领域驱动设计，那么我们主要的关注点天经地义应该放在怎样设计领域模子上，以及对领域模子的划分。

　　领域并不是何等高深的观点，好比，一个保险公司的领域中包罗了保险单、理赔和再保险等观点；一个电商网站的领域包罗了产物名录、订单、发票、库存和物流的观点。这里，我主要讲讲对领域的划分，即将一个大的领域划分成若干个子域。

　　在一样平常开发中，我们通常会将一个大型的软件系统拆分成若干个子系统。这种

　　划分有可能是基于架构方面的思量，也有可能是基于基础设施的。可是在DDD中，我们对系统的划分是基于领域的，也即是基于营业的。

　　于是，问题也来了：首先，哪些观点应该建模在哪些子系统内里？我们可能会发现一个领域观点建模在子系统A中是可以的，而建模在子系统B中似乎也合乎情理。第二个问题是，各个子系统之间的应该怎样集成？有人可能会说，这不简朴得就像客户端挪用服务端那么简朴吗？问题在于，两个系统之间的集成涉及到基础设施和差别领域观点在两个系统之间的翻译，稍不注重，这些观点就会对我们经心建立好的领域模子造成污染。

 1/5    1 2 3 4 5 下一页 尾页