Day 22 「戏如人生」以真实案例分析 Clean Architecture 的分层原则

相信大家或多或少都有去公家机关办事的经验。去公家机关办事时，如果等待时间拖太久，肯定觉得很烦吧？好不容易等到了，这时万一办事员再来一句：「资料不足，回家补足再来！」哇，一下午就这样去了！「资料不足这种小事，早点跟我说不行吗？」离开时口中不自觉唠叨的经验，肯定也不少有吧？

号码牌示意图，图片截自虾皮购物

今天我们要来实际预演一下，看看在收到一个需求後，到底要怎麽安排 Clean Architecture 的四层架构。

人生如戏

程序，就是让电脑去解决你真实世界发生的问题。而根据引用的不同理论，或是使用了不同的设计方式，解决的方式也不同。譬如「物件导向」程序，则是试图将真实世界参与一件事情的人事物，都用「物件与物件间的互动」来模拟。我知道很抽像。没关系，最好理解抽象描述的方法就是举例！

我们回到许久不见的教务处。在几十年前没有电脑的年代，人们是怎麽「申请奖学金」的？假设你准备要申请奖学金了，你在家填好申请单，走进教务处，接下来发生的事会有哪些？我们来试着在脑中演练一下…

首先，门口会有一位工读生上前招呼，并且询问你的来意。在了解你的来意後，会先检查你的申请表是否有确实填写，以免你因为一些资料不完整而被退件，浪费教务处专员的时间，以及，当然，你的等待时间。

接着，工读生会引导你去一个写着「奖学金申请」的柜台前椅子上坐下来排队等候。等轮到你时，负责的专员会叫你的名字，请你上前办理。专员会接过你的申请单，接着做一连串动作：

调出相关资料：专员会需要你的学籍资料，以及该奖学金的规章与现在申请状况。这些资料不在他手上，他得转头向一位（或一些）档案管理员调阅，而档案管理员收到请求後，则是转身从身後的档案柜翻找出你的资料。在过去没有电脑的年代，他们只能这麽做。
确认身份与资料：这里的确认与前台工读生的不同，因为这里不只是检查表格有没有填正确，而是要确保你是本校学生、申请的奖学金资格相符、申请日没有过期等。这些资料是工读生没有权限查询的。
填写官方记录：你带来的申请单是自己写的，没有经过官方认证，也没有关防，不算正式记录，它只能提供讯息给专员参考。待专员经过上述的查阅资料与审核後，如果一切没问题，专员就需要撰写一份「正式的、官方的」申请记录，并在上面署名且盖上关防。
存档并回覆：最後，专员会把这份正式文件转头交给身後的档案管理员，收入档案柜，正式成案，再开立一张收据给你，完成申请流程。

在以前没有电脑的年代，（我猜想）学校的教务处就是这麽处理「申请奖学金」的工作的。

回到现代，我们的物件导向程序该怎麽模拟上述的流程？该创建哪些物件？这些物件又该被放在 Clean Architecture 的哪一层？以下是笔者自己的分析结果，各位可以参考一下：

登场人物	任务	物件名	分层
工读生	询问来者意图，初步检查文件完整性，为其带路，找到合适的专员	ApplyScholarshipController	Adapter
申请书	写着申请资料，专员审核时可以参考	ApplicationForm	UI/Adapter
「奖学金申请」专员	控管流程，根据申请书的资料，向档案管理员索取资料，依规定审核後填写正式记录	ApplyScholarshipService	Use Case
档案管理员	依专员需求，找出资料或储存资料	ScholarshipRepository	Use Case / Adapter
「奖学金申请」正式记录	记载此申请的官方资料与核心运算（如有需要）	ScholarshipApplication	Entity
档案柜	存放档案	-	DB

上述是笔者针对真实世界的案例，分析出的一些重要物件、其主要任务，与其在 Clean Architecture 阶层架构中的所在位置。

下一篇起，我们会从 Interface Adapter 开始，一层一层地往下实作与测试，大致上会依照上表的规划，但如有需要修正或重构，将会当场修正。

谜之声：「人生如戏，戏如人生。」