写点什么

浅析整洁架构之道 (三) 明析分层原则

用户头像
御剑
关注
发布于: 2021 年 01 月 26 日
浅析整洁架构之道(三) 明析分层原则

1. 整洁架构的分层概述


在我们开始之前,我们再次回到 The Clean Architecture 的这个概述图上来。上篇文章笔者论述了 The Clean Architecture 整洁架构的基本理念,分层及黄金法则。


这一次笔者将就分层做更详细的说明与解释。


在这个概述图上,The Clean Architecture 按照环形区分为以下几层:


  1. Entities

  2. Use Cases

  3. Interface Adapters

  4. Frameworks and Drivers.


笔者就这几个层的概念及理解进行逐个解释。


其实如果我们认真对比,会发现这个模型与 DDD 领域驱动思想有异曲同工之妙。后续笔者会再就 DDD 做专门的论述。


2. 分层


2.1 Entities


这一层为『实体』层,它应该是你系统业务的核心所在。


我们都知道,任何一个系统,最终本质上都是业务的支撑与反应。比如一个银行交易系统,一定是先有银行交易的业务,再有系统,系统的形式也可以多样化,如 WEB 端,手机端,ATM 机等。


如果基于这个场景来分析,那交易本身相关的业务逻辑,就应该放在 Entities 层,如转帐,存钱,取钱等,这些属于业务核心。你应该把这些业务的逻辑放在 Entities 这一层来实现。


业务是与系统无关的,一个业务一定可以有不同的系统承载形式,比如 WEB,移动,桌面客户端,或类似 ATM 等智能设备等


2.2 Use Cases


这一层为『用例』层,也就是你的系统的每一个用例在这一层都应当有对应的反应或映射。


需要明确它与 Entites 层的区别,很多人会搞混这两层的差别。


最大的一个差别在于:


Entites 关注的是核心业务,不关注系统用例


Use Cases 更关注系统有哪些需求,它并不实现核心业务,它是调用核心业务来满足用例上的需求。


再换言之,同一个业务,如银行业务,它的核心业务层,也就是 Entites 应该是同一个,与具体的系统无关,不管你的系统是 WEB 承载,还是使用手机承载,或是 ATM 机来承载,它们应该共享同一个 Entities


Use Cases 层则不一样,因为不同的系统,用例不尽相同,一个银行业务的 WEB 端与 ATM 端,其功能与输入输出都存在较大的差别,所以它们的 Use Cases 层是不一样,不同系统有自己的这一层。


这一层有个非常明显的特征,就是它应该非常薄,业务应该是由 Entites 来实现的。


这一层还包含一些非业务的行为,如日志,缓存,事务,分页等,这些大多是系统级的需求,我们通常会把这些放在这一层来实现


2.3 Interface Adapters


这一层为『适配层』


这一层其实是与 UI 关联比较紧密的,如果你是 WEB,那这一层大多可能是 MVC 所在。


如果你是 WEB 并且用的是 Spring,那这一层就是 Controller。

如果你在移动端,那这一层就是 ViewController 或 Activity。


2.4 Frameworks and Drivers.


这一层为『框架与驱动层』。这一层是实现细节。


这是什么意思?


比如你的数据库是 MYSQL,你是使用 JPA 或 Mybatis 来与数据库打交道。


再如,你使用了缓存,可能使用了 Redis 或 EHCache 来实现你的缓存。


那类似的技术实现细节就应该在这一层来实现。


记住一个重要原则:实现细节是应该推迟到最后再考虑的


当然,很多人会搞不清楚究竟怎么样才能把实现细节放到最后果来考虑,很多人可能从来没有写过类似的代码,不清楚该如何实现。因为他们在思维上,讨论一个业务时,会自然而然的想到数据库,很难想像或理解如何做到先关注业务,后关注数据实现


3 区分业务与系统需求


在实际业务分析过程中,我们很容易将业务与*系统需求*混淆,很难分的清这两者。


需要时刻在心中明确一个规则:


业务是与系统无关的,系统需求一定是与系统相关的


我们举个例,以操作日志为例。


很多系统都会存在一个需求,记录用例操作日志,比如 XX 时间,XX 做了什么操作。


大多数情况下,这是一个系统需求,因为本身大多数业务不存在这个行为,这是一个典型的因为系统带来的行为的需求。因此,这一个逻辑大多数情况下你应该放在 Use Cases 层。


但如果是类似银行等系统,记录用户行为,如张三在10月1日09:10分存了1万元钱这种并非系统带来的,而是业务本身就一定需要记录的,那这个需求应该放在 Entities 层来实现。


所以,分析具体的需求是业务行为还是系统行为是非常重要的一件事。它决定的这一块的逻辑放哪一层来实现。


4 如何实现


在明析上述分层之后,我们可以很明显再次明确:


  • 整洁架构与具体的技术无关,笔者在论述分层的过程中,未与任意具体的技术框架相关联


  • 整洁架构与技术方向无关,这些原则适应于任何方向,包含后端,移动,WEB,甚至是 ATM 等类似设备的系统


很多人会问,如何实现这样的整洁架构,很多开发人员从未使用过或考虑过类似的架构,也没有类似的经历。其实,从笔者自己在各个技术方向的实践经验来看,基本上所有的面向对象语言都是非常容易做到上述的架构的实现。


接下来,笔者会着重论述面向对象的基本原则,只要你能理解面向对象的基本原则,就会很轻松的理解如何实现整洁架构


---------------

更多优质文章,请访问笔者的个人网站 https://lingenliu.cc 或关公众号:【御剑轩】 - 致力于实践与传播优雅的编码之道



发布于: 2021 年 01 月 26 日阅读数: 34
用户头像

御剑

关注

WHATEVER IT TAKES 2018.07.15 加入

全栈式技术开发

评论 (1 条评论)

发布
用户头像
赞!最近也在二读《架构整洁之道》,结合博主的提炼加深理解,确实现实中更难的是如何合理运用这些“道”
2021 年 01 月 27 日 11:56
回复
没有更多了
浅析整洁架构之道(三) 明析分层原则