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的目的,需要在项目的各个阶段和环节贯彻。在与客户交流时需要使用,在开发人员之间交流时需要使用,在代码中也需要使用。

posted @ 2010-11-03 10:49 Nick Wang (懒人王) 阅读(...) 评论(...) 编辑 收藏