柳州网站建设,十五年品牌  Tel:4006-130-670 15877267431 / 13788620417

柳州网站建设之还在搞三层架构?了解下 DDD 分层架构的三种模式吧 !

 二维码 2
发表时间:2021-03-12 10:59

DDD(Domain Driven Design,领域驱动设计)作为一种软件开发方法,它可以帮助我们设计高质量的软件模型。在正确实现的情况下,我们通过DDD完成的设计恰恰就是软件的工作方式。UL(Ubiquitous Language,通用语言)是团队共享的语言,是DDD中最具威力的特性之一。不管你在团队中的角色如何,只要你是团队的一员,你都将使用UL。由于UL的重要性,所以需要让每个概念在各自的上下文中是清晰无歧义的,于是DDD在战略设计上提出了模式BC(Bounded Context,限界上下文)。UL和BC同时构成了DDD的两大支柱,并且它们是相辅相成的,即UL都有其确定的上下文含义,而BC中的每个概念都有**的含义。一个业务领域划分成若干个BC,它们之间通过Context Map进行集成。BC是一个显式的边界,领域模型便存在于这个边界之内。领域模型是关于某个特定业务领域的软件模型。通常,领域模型通过对象模型来实现,这些对象同时包含了数据和行为,并且表达了准确的业务含义。从广义上来讲,领域即是一个组织所做的事情以及其中所包含的一切,表示整个业务系统。由于“领域模型”包含了“领域”这个词,我们可能会认为应该为整个业务系统创建一个单一的、内聚的和全功能式的模型。然而,这并不是我们使用DDD的目标。正好相反,领域模型存在于BC内。

在微服务架构实践中,人们大量地使用了DDD中的概念和技术:

微服务中应该首先建立UL,然后再讨论领域模型。

一个微服务**不要超过一个BC,否则微服务内会存在有歧义的领域概念。

一个微服务最小不要小于一个聚合,否则会引入分布式事务的复杂度。

微服务的划分过程类似于BC的划分过程,每个微服务都有一个领域模型。

微服务间的集成可以通过Context Map来完成,比如ACL(Anticorruption Layer,防腐层)。

微服务间**采用Domain Event(领域事件)来进行交互,使得微服务可以保持松耦合。

分层架构

分层架构的一个重要原则是每层只能与位于其下方的层发生耦合。分层架构可以简单分为两种,即严格分层架构和松散分层架构。在严格分层架构 中,某层只能与位于其直接下方的层发生耦合,而在松散分层架构 中,则允许某层与它的任意下方层发生耦合。

分层架构的好处是显而易见的。首先,由于层间松散的耦合关系,使得我们可以专注于本层的设计,而不必关心其他层的设计,也不必担心自己的设计会影响其它层,对提高软件质量大有裨益。其次,分层架构使得程序结构清晰,升级和维护都变得十分容易,更改某层的具体实现代码,只要本层的接口保持稳定,其他层可以不必修改。即使本层的接口发生变化,也只影响相邻的上层,修改工作量小且错误可以控制,不会带来意外的风险。要保持程序分层架构的优点,就必须坚持层间的松散耦合关系。设计程序时,应先划分出可能的层次,以及此层次提供的接口和需要的接口。设计某层时,应尽量保持层间的隔离,仅使用下层提供的接口。关于分层架构的优点,Martin Fowler在《Patterns of Enterprise Application Architecture》一书中给出了答案:

开发人员可以只关注整个结构中的某一层。

可以很容易的用新的实现来替换原有层次的实现。

可以降低层与层之间的依赖。

有利于标准化。

利于各层逻辑的复用。

“金无足赤,人无完人”,分层架构也不可避免具有一些缺陷:

降低了系统的性能。这是显然的,因为增加了中间层,不过可以通过缓存机制来改善。

可能会导致级联的修改。这种修改尤其体现在自上而下的方向,不过可以通过依赖倒置来改善。

在每个BC中为了凸显领域模型,DDD中提出了分层架构模式。最近几年,笔者在实践DDD的过程中,也经常使用分层架构模式,本文主要分享DDD分层架构中比较经典的三种模式。

来源:芋道源码


会员登录
登录
其他帐号登录:
留言
回到顶部