DDD的目的

最近看了一点Domain Driven Design这本书，虽然里面对于如何使用Entity、Value Object、Repository、Factory、Aggregated、Service等模式做了大量讲解，但是不要忘了，最终的目的是ubiquitous language。

 

目前大多数的商业软件或者是网站，核心复杂度并不在技术方面。特别是在Web 2.0、RIA、HTML5盛行的今天，可以说Web的架构已经不是开发网站的最大挑战了。更多的挑战来源于对业务（business）的理解。开发人员只有充分理解的业务知识，才能理解需求，才能正确的实现需求，甚至审视需求的合理性和正确性。那么开发人员如何才能获取业务知识呢？和客户谈框架？和客户谈数据库？显然大多数的客户并不理解开发人员的语言，而开发人员也通常不理解客户的语言，巴别塔的传说在现实中一次次的上演。 开发人员在与客户交流的时候，要尽量忘记技术语言，虚心学习业务语言，与客户一起寻找能够共同理解和交流的词汇集，并慢慢的形成ubiquitous language。

 

 不仅在与客户交流的时候需要用到ubiquitous language，在开发人员之间交流和讨论业务需求的时候，也尽量要使用ubiquitous language。这使得开发人员可以保持以业务的思维方式进行思考，同时避免开发人员对业务理解的不一致。

 

最后，在写代码的时候，也需要用到ubiquitous language。当你用业务词汇命名类、变量和方法时，代码本身就变成了对业务的陈述， 代码本身就足以表达需求和业务，代码也就自然而然的成为更新最及时、最最真实的文档。代码即文档，是我所追求的目标，然而实现起来往往困难重重。首先，你需要知道什么样的代码是好代码（推荐《Clean Code》），什么样的设计是好的设计；然后，你还要在保持代码干净的前提下，尽量将业务规则表达出来；最后，在一个多人团队中，还要处理人员水平不同，代码质量差异的现实问题。如果代码写的不好，起不到文档的作用，最后的结果往往是业务规则的丢失：代码工作正常，功能没问题，但是没人说的清楚业务规则到底是什么，从代码中也很难看出来。

 

ubiquitous language是DDD的目的，需要在项目的各个阶段和环节贯彻。在与客户交流时需要使用，在开发人员之间交流时需要使用，在代码中也需要使用。