《架构整洁之道》第 33 章 案例分析：视频销售网站
0 / 0 / 创建于 1年前
巴啦啦 的个人博客
均为原创，读架构整洁之道的笔记。
包含了部分自己的理解，包含了原书中至少70%的知识点。
完整笔记，各位老哥友链加起来吧。
我的博客地址：www.yuque.com/_huangkuan
根据之前提到的设计规则和架构理念整合起来，做一次案例分析。
产品
这个案例分析中，产品是一个线上收费视频网站，https://cleancoders.com/，作者在这个网站上出售他的软件开发教程视频。
这个网站向个人或企业提供一批收费的线上教程。个人用户支付后可在线观看教程，也可以付费更多将视频下载下来。企业用户只能在线播放，批量购买可获取折扣。
个人用户通常既是购买者也是观看者，企业用户则不同，他们买了是给其他人看的。
视频作者需要负责上传视频，写简介，习题，课后作业，答案，源码等其他资料。
管理员需要负责新增视频播放列表，增加删除视频，并且设置价格。
系统架构设计中的第一步，是识别系统中的各种角色和用例。
用例分析
可以看到，有四个角色。根据单一职责原则（SRP），这四个角色将成为系统变更的主要驱动力。每当增改功能时，所做的一切都是在为这四个角色服务。
其中虚线框用例，称为抽象用例，它们负责设置通用策略，然后交由其他具体的用例来使用。比如查看目录这个用例，被观察者查看目录和购买者查看目录，这两个用例所继承实现。
一方面来说，抽象用例并不是必须的，因为没有这一层抽象，整个产品并不会受到影响。
但从另一方面来说，这两个用例十分相近，以某种方式将它们合并起来分析是很合理的。
组件架构
双实线为具体边界。从左至右，视图，展示器，交互器，控制器。同时按角色进行了分组，每个组件都有其自己的视图，展示器，交互器和控制器。
这里有两个特殊的组件，Catalog View和Catalog Presenter。这是查看目录列表这个抽象用例，假设这些视图和展示器将会编写为抽象类，而继承它们的组件将会包括它的派生类。
但问题是，我们真的需要将系统拆分成这么多组件，然后按组件一个个交付吗？是，又不全是。
我们要按照组件将编译和构建环境分开，以便单独构建对应组件。但是我们仍然可以将组件组合在一起进行交付。比如，我们可以将其交付为5个.jar文件，按照视图，展示器，交互器，控制器，工具类，按照这种分类进行组合一起交付。
除此之外，还可以将视图+展示器，放在同一个.jar文件中，而将其他各自放在单独的.jar文件中。还有一种更简单的，将视图+展示器，放在一个.jar中，而将其他组件合并成一个.jar中。
随着系统的演进，可以根据系统变更来调整部署方式。
依赖关系管理
上图中，控制流是从右到左的，由控制器接收用户数据，最终由View展示。但是图中的箭头并不是一直从右向左，大部分是从左向右的，因为这是依赖关系的指向，低层需要依赖于高层。使用箭头（开放箭头）和控制流方向一致，继承箭头（闭合空心箭头）则相反，它反映的是开闭原则的应用，通过调整依赖关系，可以保证低层细节不会影响到高层策略。
本章小结
上图中，实现的是两个维度的隔离。
- 根据
单一职责原则对系统中的各个角色进行隔离。 - 对
依赖关系原则的应用。
这两个维度都是为了将不同变化原因和不同变更速率的组件隔离。比如变更原因不同是因为组件的使用角色不同，变更速率则取决于组件所处层级（层级越高变更速率应该越慢）。
如此组织代码结构，可以在部署时灵活选择调整。
本作品采用《CC 协议》，转载必须注明作者和本文链接
关于 LearnKu
粤公网安备 44030502004330号