最近圈里对DDD的讨论越来越多了，什么战略设计、战术设计、聚合、限界上下文、值对象。有求代码示例的，还有的人写了“DDD框架”。慢慢的，我感觉，DDD有一种被神化了的感觉，它能解决很多以前我们解决不了的问题，比如：代码烂。同时DDD又有一种神秘感，很多人不知道应该怎么做或者说怎么写代码。然后网上就诞生了很多神奇（hu shuo ba dao）的文章甚至是DDD框架，实践方法越来越扑朔迷离。今天我就来扒一扒DDD和我对它的一点理解。
历史
Eric Evans在2004年写了一本书叫 Domain-Driven Design: Tackling Complexity in the Heart of Software,然后就有了DDD，从此以后提到domain似乎就是源自于这本书。但是，并不是这样的啊兄弟们！2002年Martin Fowler写了一本书叫Patterns of Enterprise Application Architecture,这本书中提到了一种Domain logic pattern叫Domain Model也就是领域模型。而且书中有一句话：
Eric Evans is currently writing a book [Evans] on building Domain Models. As I write this I’ve seen only an early manuscript, but it looks very promising.
所以领域模型这个概念并不是DDD提出的，这玩意早就有了。而领域模型的本质就是面向对象编程（OOP）。以我目前的职业生涯所见，面向对象编程这个技能，在国内的java开发者里就很少有人掌握（没错，你整天拿java撸的代码并不OOP），而企业中用的最多的模式是事务脚本模式(Transcation script)，这玩意基本没啥OOP的特点。所以大家觉得领域模型不知道该从何下手就很正常了，因为连基本OOP都没整明白更别提建模了。更重要的是领域模型的建立严重依赖于建模人甚至是整个团队的技术经验和能力，这就更雪上加霜了。Martin Fowler在书中也提到了领域模型的缺点：
Yet the Domain Model (116) has its faults. High on the list is the difficulty of learning how to use a domain model. Object bigots often look down their noses at people who just don’t get objects, but the consequence is that a Domain Model (116) requires skill if it’s to be done well—done poorly it’s a disaster.
翻译过来就是：学习成本很高，并且需要非常专业的技术和技巧，如果处理不好就是一场灾难。还有另一个比较棘手的问题：领域模型的持久化映射，这可能是搞DDD的人第一个要面对的问题，这个以后会写文章专门说。最后，说了这么多，其实最重要的是转变思想：模型不是表结构，设计模型不是设计数据表结构，先忘了数据库吧，它只是一种存储设施，要想整明白DDD先整明白OOP。另外：我在 写点野路子代码 中也大概说了一下OOP，需要的人可以从代码的层面感受一下有什么不一样。
DDD在说什么
有人可能会问了，DDD就没啥新鲜玩意？当然不是。DDD的全称是Domain driven design,design什么呢？对，就是领域模型，采用DDD的团队的主要产出就是领域模型。领域模型中富含了丰富的业务知识，并且模型与代码应该是一致的。如果模型脱离了代码，那模型可能就会变的天马行空，不着边际，所以保持代码和模型的一致是非常重要的。模型是业务方与技术方共同开发出来的。他们使用的语言就叫做统一语言（ubiquitous language)。整个模型的开发过程是这样的：
- 业务方与开发方通过一些方法（比如：事件风暴）建立初步的模型，然后大家一起验证模型是否满足业务，模型验证完毕后提取统一语言。
- 如果模型发生了变化，大家对模型进行修改，验证完毕后将模型的修改反映到统一语言上。
- 如果从统一语言中发现了新的概念，修改模型使之与统一语言一致。
- 通过这样的不断迭代使模型越来越接近真实的业务。
因为统一语言是与领域模型关联的，而统一语言又是大家共同开发出来的，也就是共同拥有的，所以这就给技术方和业务方赋予了相同的权责和义务。
- 技术方权责：通过修改统一语言影响模型进而影响业务，也就是技术方可以定义业务。
- 业务方权责：通过修改统一语言影响模型进而影响代码，也就是业务方可以影响技术。
- 技术方义务：将模型反映到代码上
- 业务方义务：将模型的修改反映到业务上
这使得技术方与业务方的合作非常紧密（让我想起了BDD),并且有基于领域模型的共同的理解。最后就是模型的代码实现了，这又是一个大话题，改天再聊~
网友评论