领域驱动设计——模型的完整性设计

一、战略设计和战术设计

说起战略和战术，似乎很高大上的样子，其实在这里战略就是从整体抽象的角度来看设计；战术是具体的设计方法和设计模式。或者换一句话来说，前者考虑是的大的方向大的问题，后者考虑的细节和具体成型。战略设计强调问题空间和解的空间，而战术设计更强调界限上下文中的领域建模。
战略设计和战术设计是互相影响不断演进的过程。

二、模型的完整性设计

所谓模型的完整性，其实非常容易理解。在实际的开发过程中，人们习惯于对代码的重用，也就是说，如果有人告诉说有一个现成的实现某某功能的模块可以用，大多数人会直接采用。可是，有没有想到，这个模块是不是适合在自己的领域中应用，会不会引入什么副作用？所谓功能的实现会不会受其它接口的影响等等。这些都会增加模型的不确定性也就是不完整性。
在实际的领域设计中，一定要保持模型内部一致，术语意义相同不产生歧义。但在实践的过程中，往往因为各种原因，大型的软件会有多个模型，一种暴力的想法是可不可以把它们完全统一到一起来。这确实是一种很好的想法，但也是一种非常难于实现的想法，因为统一就意味着巨大的经济成本，而这个巨大的成本，即使对于一些超级经济体也是难于承受的。更多的是，这种想法是没人原意去实现的。
基于此，就需要一些好的设计思想和模式来解决这种问题，既把这种多个模型的限界划清楚，又能够在合理的范围内进行有效的沟通。

三、相关模式

1、BOUNDED CONTEXT
这个其实就是现实社会中经常提到的人和人之间要有边界感，要给每个人有自己的私人空间。同样是吃饭，有的人就原意在桌子上吃，有的人则原意在炕上吃，为什么非要统一到桌子上吃呢？而在领域设计中，有些领域就需要用缓存来解决问题，有的则用存储解决问题，同样的存储模型，可能就完全不一样。反过来也一样，如果有别人也用了缓存存储模型，又和另外一个缓存存储模型有共用场景上下文，那么就需要把这个缓存模型统一到一起，才不至于出什么乱子。

2、CONTINUOUS INTEGRATION
CONTINUOUS INTEGRATION是指把一个上下文中的所有工作足够频繁地合并到 一起，并使它们保持一致，以便当模型发生分裂时，可以迅速发现并纠正问题。像领域驱动设计中的其他方法一样，它分为两个级别： 模型概念的集成和 实现的集成。持续集成和XP编程很相似。其实在前面也提到过，模型本身就是一个不断完善的动态稳定的过程。

3、CONTEXT MAP
它其实是一个整体视图的感觉，也就是说，整体看这些边界才更清晰。就如看地图，只看一个小地方，根本无法知道具体的位置。它其实是项目管理和软件设计的重叠部分。

4、SHARED KERNEL
SHARED KERNEL一般是Core Domain，它是为了减少重复。看到这，是不是想到了公共库、DLL和基础类等等这些可以公用的东西。对这两个本质是一样的。不过基于领域设计，这个SHARED KERNEL一定是多个团队共同管理，共同测试，共同修改和完善的。是多个团队的公共子集或者说领域内的公共子集。

5、CUSTOMER/SUPPLIER DEVELOPMENT TEAM
客户/供应商开发团队模式，看名字就了解，它其实是一种服务依赖的关系。这点要和前面的Share Kernel分开。前者更倾向于一方对另一方的应用，而非共享。明白这一点，就可以正确把握二者的不同。一个是平等共用，一个是依赖服务。它有一个前提，必须有一个共同的管理者或者说根。

6、CONFORMIST
当两个上下文不归属于同一个根时，CUSTOMER/SUPPLIER DEVELOPMENT TEAM是不适用的，这时候就可以使用追随者模式，它的重点在于是对于一个有意义的现有的模型的集成。这个概念一定要弄明白，这是掌握追随者模式的一个重要前提。
7、ANTICORRUPTION LAYER
防腐层有点类似于设计模式里面的适配器模式，在实际的领域设计中，经常会有大量的现有的系统需要兼容，那么又尽力想降低兼容双方的耦合度，减少互相影响造成的不良后果，这就需要有一个防腐层，来专门解释相关的内容对双方的模型进行交互。

8、SEPARATE WAY
各行其道，其实就是单一职责，能单独自己设计尽量不要掺和别的领域。自己的事情自己干，当然前提是得能自己干。

9、OPEN HOST SERVICE
这个其实更好理解，在前面分析了一两个领域的交互解决的方式，但如果是很多呢？如果是不同的公司的领域呢？这就需要定一些协议，把交互的标准准备好。大家都明白，公用即可。

10、PUBLISHED LANGUAGE
这个就更容易了，其实就是通用一种语言，类似于全国都讲普通话一样。比如常见的XML、Json等等，都可以起到相同的作用。

四、总结

领域设计虽然不是一个多新的设计方式，但国内真正被重视起来就是这几年，而且也没有什么特别经典的重磅例子，不像设计模式啥的，随便弄一个都非常容易理解。本身做到领域设计这个层次的开发设计人员就是少数，所以也就不要强迫自己一定要把领域设计搞得多么通透。那为啥要学它？肯定有这个疑问。
学它的目的就是要在实践中应用它，然后真正的理解和使用它。从必然王国迈向自由王国。