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

一、战略设计和战术设计

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

二、模型的完整性设计

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

三、相关模式

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等等,都可以起到相同的作用。

四、总结

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

你可能感兴趣的:(架构设计,DDD)