关于架构设计的易变性,应该如何理解呢?

一、架构设计分层

通常情况下,我们的架构设计图大概率会如下图这个样子了,首先声明一点,这其实并没有什么不妥的,这也是很典型的分层设计啦~

关于架构设计的易变性,应该如何理解呢?

关于各个分层的具体描述,就简单的来聊聊吧。

Client层

这个比较简单,就不多说了。

Business Logic

业务逻辑这层分成 Manager 和 Engine 层,Manager 负责管理流程类的易变性,Engine 负责某个活动节点本身的易变性。

什么是流程易变性呢?简单理解,就是工作流嘛。

关于架构设计的易变性,应该如何理解呢?

下面的两个流程是完全相同的,只是在第二步使用的活动不一样,如果 B 和 D 干的是同一件事情,那么 B 和 D 应该被封装进同一个 Engine 中。

关于架构设计的易变性,应该如何理解呢?

当然,如果 B 和 D 功能不一样,那这两个流程就不一样了,另论。

Resource Access

这一层是资源访问层,负责一些存储资源的封装,也就是说公司内的基础设施要变化的时候,不应该影响到上层的业务,这种在 DDD 社区也有 Repo Pattern 之类的,比较好理解。

Utilities

那些紫色的组件,一般是一些大家公用的非功能性 SDK,也比较好理解。

架构图里的模块大多是服务:

关于架构设计的易变性,应该如何理解呢?

这样的分层每一次都是在解决 Who、What、How、Where 这四个问题:

关于架构设计的易变性,应该如何理解呢?

从上往下,易变性是逐渐降低的,这个我们可以理解,公司里最常修改的都是上面的一些业务逻辑,底层的基础设施几年变一次就不错了。

自上而下的重用性是逐渐增加的,Manager 经常做变更、重构、完全重写,都是挺正常的。

二、架构组合设计方案

开放架构

任何组件都可以调用任何其它组件,而不必考虑组件所在的层。可以向上向下调用。

开发架构有很大的灵活性,不过显然会导致层与层之间互相耦合,层内的横向调用也会导致层内的相互耦合,这样的项目是没法维护的。

作者认为产生横向调用是因为架构按照功能分解的恶果之一。

封闭架构

封闭架构禁止层内的横向调用,并且禁止下层调用上层系统。

这样才能发挥分层的优势,将层与层之间解耦。

封闭架构只允许一层的组件调用相邻较低层中的组件,下层的组件封装更下层的逻辑。

半封闭半开放架构

基础设施的关键部分,有时互相调用是难以避免的。因为基础设施要考虑性能问题,必须要进行最大优化,而有时向下转换会导致性能问题。

但大多系统不需要半开半闭,只要封闭就可以了。

放宽一点封闭架构的规则

因为封闭架构的要求太苛刻,实际开发中确实会遇到问题,在下面这些情况下也可以酌情放宽:

  • 调用 utilities
  • 按业务逻辑访问资源访问,即 manager 层直接调用 resource access 层
  • manager 组件调用不太相邻的引擎
  • manager 组件到其它 manager 组件通过 MQ 来通信,这种情况 manager 组件不需要知道其它组件,只要发 message 就可以了

设计禁忌

下面这些行为都是不能允许的:

  • Client 不应该在一个用例中调用多个 Manager,不应该直接调用 Engine
  • Engine 不应该发布消息,不应该订阅消息队列
  • Engine 与 Manager 不应该相互调用

三、总结

关于可组合架构与架构验证,一定不要根据需求设计,而是要根据易变性来设计。

设计系统时,要从需求列表中找到核心需求,在设计完成之后,先用核心用例进行架构验证。在增加新的需求时,应该不太需要变更架构,这才说明这套架构设计对了。

发表评论

相关文章