7.3.2 领域驱动
领域驱动设计关心的是业务中的领域划分(战略设计)和领域建模(战术设计),其开发过程不再以数据模型为起点,而是以领域模型为出发点,研发过程如图7-4所示。领域模型对应的是业务实体,在程序中主要表现为类、聚合根和值对象,它更加关注业务语义的显性化表达,而不是数据的存储和数据之间的关系。这是“领域驱动设计”和“数据驱动设计”之间显著的区别。
仍以上面的CRM为例。假如我们先不考虑数据模型,而是采用面向对象分析(Object Oriented Analysis,OOA)对这个场景进行领域建模,那么可以得到图7-5所示的领域模型。
可以看到,在图7-5中,领域模型的描述更加贴近业务,一些重要的业务术语和概念没有丢失,更完整地表达了业务语义。即使是产品经理或者业务人员,也不难看懂这样的领域模型,甚至他们可以和技术人员一起参与到梳理领域模型和创建活动中来。
通过DDD的战略设计和战术设计,我们可以为问题域划分出合适的子域,并对域中的业务进行建模。图7-6所示是我们在实际工作中为CRM进行的领域战略设计。
7.3.3 ORM
很明显,领域模型和数据模型并不是一一对应的关系,但也不排除,有些情况领域模型和数据模型是趋同的,但是大部分情况都需要做一层映射(Mapping)。为了弥补二者之间的差异,行业先驱们做了很多关于映射工作的尝试,这种技术有一个名称叫作对象关系映射(Object Relationship Mapping,ORM),如图7-7所示。
ORM曾经非常火,记得当年Hibernate才出现时,我用尽了其中的高级技巧,比如继承关系映射、多对多关系映射……结果弄出来的东西却变成了“四不像”,既不像Entity,也不像数据对象(Data Object,DO)。
ORM的问题在于它太理想化,期望通过工具把数据建模和领域建模合一,这样的尝试注定是很难成功的。仍以上述的CRM案例为例,在数据模型中根本就没有私海和公海这两个实体,工具是无法映射的。因此,Hibernate和JPA的衰落是可以预见的。现在使用最多的是MyBatis,它很简单,完全不理会复杂的关系和对象之间的复杂关系映射,只做数据库表和DO之间的简单映射。
复杂的数据库关系和对象关系之间的差异,其本质是数据模型和领域模型之间的差异,而这种差异的多样性和灵活性是很难通过规则预先定义的,这也是为什么工具的作用会很有限。现在的互联网大厂大多使用MyBatis,原因也在于此。因此,如果你打算实践DDD,请一定不要让工具帮你去建模,工具不会抽象,也不会思考,还是要老老实实自己动手去建。
编后语:张建飞说过,他最希望将《代码精进之路》推荐给职场新人看,因为如果在你初入职场的时候,就有一个人教你怎么写好代码,那一定是一件很幸运的事情。
“种一棵树最好的时间是在十年前,其次是现在”。我不相信什么“35岁做不了程序员”,也不相信什么“年纪大了,精力不够”。我只知道有些人在持续学习,有些人过早地享受安逸。
愿你在新的一年可以快乐,也能有所收获。