领域驱动设计优势
1.领域模型边界不清晰,无法支持分布式架构:领域建模阶段往往使用面向对象的建模方式,缺少对象间的明确边界。将此方法运用到SOA架构或微服务架构中以后,不同的类将会被分散在不同的服务中,因此需要尽量避免跨越服务边界的对象引用。
比较通用的做法是独立设计、开发每个服务。
对于需要相互协作的服务,由于没有统一领域模型往往会引起数据重复且无法打通,造成严重的烟囱效应。
2.缺乏统一语言,代码难以理解:因为应用开发的不同阶段采用不同的语言,往往经过过滤和翻译转换,因此存在遗漏、曲解的问题,而这些问题直到上线才会暴露。业务逻辑不能从产品团队精准传递到开发团队,有时开发团队开发了一段时间后才发现需求理解有偏差。
3.缺乏合理抽象:在领域复杂度问题上,业务人员不能代替领域专家。没有领域专家的协助,往往无法很好地解决复杂度问题。同时开发团队面对需求增长和变化时,缺乏对业务逻辑的抽象和理解,往往开发一个需求点需要改动多处,容易出错且导致开发效率低、代码可维护性差。
DDD是对面向对象设计思路的升级,它希望通过统一的模型打通业务、需求、设计、开发等不同阶段,用一套模型充分反映领域专家、架构师和开发人员的共识,使应用能够更灵活、快速地响应需求变化,使应用即使变得更复杂也仍然能保持敏捷性。
1.通用语言
DDD的一个核心原则是使用一种基于模型的语言,因为模型是基于领域共同点而建立的,很适合作为通用语言的架构基础。使用模型作为语言的核心骨架,要求团队在进行交流时使用一致的语言,而且代码也是基于该语言模型的,确保团队使用的语言在所有交流形式中保持一致。
2.协作设计
在建立模型时就考虑到应用的设计和开发,开发人员参与到建模工作中,主要目的是选择一个恰当的模型,这个模型能够对应用开发过程有所呈现,这样一来,基于模型的开发过程就会很顺畅。将代码和模型紧密关联会让代码更有意义,且代码能随着模型的调整而调整。
3.支持分布式架构
为了解决分布式应用领域建模的困扰,通过建立统一领域模型,划分子领域边界,使用通用子领域来实现数据同步共享。分布式事务处理也可以通过DDD的聚合机制来维护服务之间的数据一致性。