重構既有系統，邁向整潔架構 （4）：第一回合，分層與移除基本型別依戀

September 16 17:48~18:40；19:49~20:39

▲從下層爬往上層的咪咪 (by 常玉)

 

工商服務

想了解本系列文章完整內容，請參考【重構既有系統：邁向整潔架構實作班】。課程介紹與報名網址在此：https://teddysoft.tw/courses/refactor-to-ca/。

***

前言

前三集聊了：

1. 重構既有系統，邁向整潔架構 （1）：為什麼透過重構改善軟體架構很困難

2. 重構既有系統，邁向整潔架構 （2）：逆轉重構流程

3. 重構既有系統，邁向整潔架構 （3）：Task List Kata簡介

這一集終於要動手重構。

***

分層原則

Teddy在第二集提到要採用由上而下的方式來重構，首先套用Clean Architecture，確定架構分為四層，如圖1所示。

 

▲圖1：套用Clean Architecture的分層原則

 

其中Task這支只有不到30行的程式很明顯地屬於Entities Layer，將它移到entity package。150行的TaskList目前還不清楚屬於哪一層，先不移動它。

 

***

 

物件村沒人怎麼辦？

Teddy的重構目標是在架構上採用Clean Architecture，在Entities Layer與Use Cases Layer則是套用DDD（領域驅動設計）的戰略模式語言（Entity, Value Object, Service, Aggregate, Repository等）。現在「物件村（domain model）」只有一個Task，顯得有點孤單，要想辦法增加物件村的人口。

 

物件導向設計，顧名思義就是要透過物件（領域模型）來表達問題領域的業務邏輯。這個Task List Kata重構範例只有兩個物件，這種現象有一個可能性，就是設計者對於「基本型別依戀」，捨不得使用物件，只用了String, Int這些基本型別。因此，接下來Teddy要採用「只管移除基本型別依戀」的方式，來增加物件村的人口。

 

***

 

無腦移除基本型別依戀

請參考圖2，第17行Map<String, List<Task>> tasks，將它「座艙升等」成Tasks物件，如圖3所示。

 

▲圖2：TaskList程式碼片段

 

 

 

▲圖3：移除基本型別依戀，新增Tasks物件

 

***

套用Value Object

圖3中的Map<String, List<Task>> tasks，其中Map的key代表project name，因此將其座艙升等成Value Object，請參考圖4。

 

▲圖4：ProjectName value object，用Java record代表

 

***

 

引入共通語言（Ubiquitous Language）

請參考圖5，此時Tasks類別的第6行變成Map<ProjectName, List<Task>> tasks，這還是一個基本型別依戀。請問一個擁有一組Project Name對應到List<Task>的「概念」要怎麼稱呼它？在此Teddy將其稱為Project。因此我們進一步將Map<ProjectName, List<Task>> tasks重構成List<Project> projects，參考圖6。

 

▲圖5：Tasks類別

 

 

▲圖6：Project類別

 

 

最後，Teddy把Tasks類別改名成ToDoList，現在物件村已經有四個物件，請參考圖7。

 

▲圖7：物件村從1個住戶增加為四個住戶

 

***

 

下集預告

有了物件村的住戶（領域模型），下一集要在領域模型中套用DDD戰術模式（tactical design patterns），好好了解一下什麼叫做Aggregate, Entity, Value Object。

***

友藏內心獨白：只有一個物件變成全村的希望，這樣壓力太大。