DDD(Domain Driven Design)作为一种软件开发方法,它可以帮助我们设计高质量的软件模型。在正确实现的情况下,我们通过 DDD 完成的设计恰恰就是软件的工作方式。
微服务近年来可谓炙手可热,合理的使用微服务架构可以解耦系统,提供更好的软件伸缩性以及提高组织的敏捷性,然而微服务架构从一出来就没有很好的理论支撑如何合理的划分服务边界,人们常常为服务要划分多大而争吵不休。而 DDD 被发现恰好可以弥补微服务的营养不良:通过战略设计可以确定子域并在子域内划分 BC(Bounded Context),一个微服务一般对应一个 BC,同时 BC 内成熟的分层架构和战术设计可以应用在微服务上。
很多团队在微服务内实践 DDD 时,经常会为如何分包而纠结来纠结去,折腾了很长时间也很难满意,同时不同团队,甚至同一团队的不同开发人员的分包原则和方式也大不相同,非常不利于产品代码的开发和维护。我们说的物理设计,主要就是目录和文件设计,可以很好的解决分包问题。
本场 Chat 首先回顾了DDD的基本知识,并将微服务与DDD关联在一起,然后介绍了DDD四层架构模式,为阐述微服务的物理设计打好了必要的基础,接着详细阐述了DDD在微服务物理设计中的应用,并输出了微服务物理设计的推荐方案,以及物理设计经过DCI(Data,Context and Interactive)架构模式、Domain Event建模元素和DIP(Dependency Inversion Principle, DIP)原则驱动后的演进方案,最后列出了作者精心准备的放在github上的多个代码案例,从而有效降低落地难度。希望读者吃透本场 Chat 的知识点,举一反三,灵活应用DDD做好微服务的物理设计,并参考案例代码将其真正落地。
本场 Chat 你将学到以下内容:
绑定成功
预订达标,作者开始写作
审核未达标,本场 Chat 终止
审核达标,文章发布
审核未达标,本场 Chat 终止