如何閱讀模型驅動設計建構區塊的模式語言

Dec. 06 21:40~23:10

▲圖1：Model-Driven Design模式語言，節錄自藍皮書

模式語言範例

《Domain-Driven Design: Tackling Complexity in the Heart of Software》（藍皮書）Part II，「The Building Blocks of a Model-Driven Design（模型驅設計的建構區塊） 」有一張圖（ 如圖1所示），代表Model-Driven Design模式語言。

這個模式語言代表DDD單一bounded context內的核心模式，今天Teddy要談一下如何閱讀這個模式語言。

***

模式語言

模式語言由建築師Christopher Alexander所發明，透過一組有方向性的模式來解決一個大的設計問題。一個模式語言最頂端的模式，代表使用這個語言的人想要「製作出來的東西」。在圖1中，模式語言第一個模式是Model-Driven Design（模式驅動設計），它本身是一個DDD模式。這是一個比較大（或是說比較抽象、比較高層次）的模式，為了落實Model-Driven Design，需要依靠它下方第一層的其他四個模式，讓Model-Driven Design更完整：

• Service
• Entity
• Value Object
• Layered Architecture

Service模式下方沒有其他模式，代表Service模式本身不特別需要其他模式來支持它就已經很完整。Entity模式則需要Aggregate、Repository與Factory這三個模式使其完整。Entity可透過Factory來產生實例。Aggregate包含Entity與Value Object，Entity也需要倚靠Aggregate來確保資料的完整性。

在圖1中，標示著Entity透過Repository來存取，但Teddy認為其實這個關係可以不用畫在模式語言中，因為Aggregate才會有Repository，單獨的Entity是不能透過Repository來存取。客戶端只能透過Aggregate Root來讀取Aggregate內部的Entity。

***

Value Object下方則有Aggregate與Factory，這個關係很清楚，就不解釋了。Aggregate下方則有Repository與Factory，分別用來儲存與讀取以及生成Aggregate。

***

Model-Driven Design下方最後一個Layered Architecture模式，比起前述其他模式都要大得多。前面幾個模式算是「設計模式」，Layered Architecture已經是「架構模式」。嚴格說起來，Layered Architecture下方還是可以展開其他模式來支持它的實作。

還有一點要注意，在藍皮書中，對於Layered Architecture模式的描述，屬於傳統階層式架構，階層之間的相依性是由上往下，上層依賴於下層。以現在的角度來看，這種解法應該改套用dependency inversion（相依反轉）原則，拿掉上層對於下層的直接依賴。

如果是Teddy現在來畫這個模式語言，會用Clean Architecture模式來取代Layered Architecture。

▲中文版《領域驅動設計》第68頁描述Layered Architecture模式的解決方案。

***

最後，圖1還有一個Smart UI模式，但是它與Model-Driven Design模式之間卻出現一個X符號。Teddy在Alexander原始的模式語言中並沒有看過這種表示方法，作者的用意只是提醒讀者，Smart UI與Model-Driven Design彼此互斥。

***

重畫Model-Driven Design模式語言

▲圖2：Teddy重劃後的Model-Driven Design模式語言

依據以上討論，圖2是Teddy重畫後的Model-Driven Design模式語言。Teddy習慣由上而下來畫製模式語言，而非像藍皮書中由左而右繪製。自己重新整理之後，感覺比藍皮書的版本還要清爽與容易記憶 XD。

***

工商服務

對於領域驅動設計（Domain-Driven Design；DDD）與簡潔架構（Clean Architecture）有興趣的鄉民，歡迎參加泰迪軟體的【領域驅動設計與簡潔架構入門實作班】。

對於設計模式有興趣的鄉民，歡迎參加泰迪軟體的【Design Patterns這樣學就會了–入門實作班】。

***

友藏內心獨白：用模式語言思考可以看到問題全貌。

把問題寫成一個問句

Dec. 04 08:29~10:25

選擇解決方案的困難

使用設計模式（design pattern）超過20年，也教了好幾年的設計模式。Teddy發現一個常見的問題，就是遇到設計問題時，不知道要套用哪一個設計模式。

Teddy一直覺得，讀模式除了模式名字（Name）以外，最重要的就是要知道模式要解決什麼問題 （Problem），最好能夠把問題寫成一個問句，用一句話就能說出該模式存在的目的。

如此一來，在套用模式的時候，針對解決相同問題的模式，只要考慮他們彼此之間forces的差異，就可以判斷哪一個解決方案比較合適。

可惜很多模式的撰寫風格並沒有明確指出模式所要解決的問題，而是使用敘述性的文字把問題與forces甚至是解決方案混在一起談論。讀者只關注到模式的解決方案，導致誤用模式的情況。

***

Value Object

▲翻拍自《Domain-Driven Design: Tackling Complexity in the Heart of Software》，p.98 。

上圖為《Domain-Driven Design: Tackling Complexity in the Heart of Software》（藍皮書）書中描述Value Object模式的段落，黑體字的部分指出幾點問題，這個看起來好像是Value Object所要解決的問題（從Teddy的角度來看，黑體字的部分比較像是forces，也就是問題的限制或特徵）。但是，讀完之後還是不知道如何用一句話說明Value Object的Problem。

黑體字之後突然冒出一句「An object that represents a descriptive aspect of the domain with no conceptual identity is called a VALUE OBJECT 」，這看起來像是在說明解決方案。一下子討論問題，突然又冒出解決方案（書中下一頁才是詳細的解決方案章節），更容易讓讀者抓不住模式所要解決的問題到底是什麼。

***

改寫練習

藍皮書第五章A Model Expressed in Software提到了四個模式：ENTITY、VALUE OBJECT、SERVICE、MODULE，Teddy認為它們都要解決一個共同的大問題。因為forces不同，所以衍生出四種不同的解決方案（四個不同的模式）。

在此Teddy試著改寫前三個模式，它們擁有相同的Context以及Problem：

Context：你正在使用物件導向方法定義領域模型。

Problem：你如何表達物件（領域元素）？

***

ENTITY

Forces:

• 物件不是由其屬性所定義。
• 兩個屬性不同的物件可能被視為相同。
• 即使兩個物件具有相同的屬性，它們可能被視為不同的物件。
• 弄錯物件辨識碼可能導致資料損壞。

Solution：將物件歸類為ENTITY如果它是透過辨識碼而不是自身的屬性來區分。使此辨識碼成為模型中其定義的主要依據。使類別定義保持簡單，並專注於生命週期的連續性和標識。定義一種區分每個物件的方法，無論其形式或歷史如何皆可依據該方找到想要找的物件。將需求中依據屬性匹配物件的要求改成依據辨識碼。定義一個保證為每個物件匹配產生唯一結果的操作，可能透過附加一個保證唯一的符號來實現。這種標識方式可能來自外部，也可能是系統為系統創建的任意標識符號，但必須與模型中的辨識碼相對應。模型必須規範物件相等的定義。

***

VALUE OBJECT

Forces:

• 物件由它們的屬性定義。你只關心它們是什麼，而不關心它們是誰。
• 紀錄物件的識別碼至關重要，但是將識別碼附加到每個物件身上可能會損害系統性能，增加分析工作並弄亂模型，使所有物件看起來都一樣。

Solution：當你只關心物件的屬性時，將物件分類為VALUE OBJECT。使它表達其傳達屬性的含義並賦予它相關的功能。將VALUE OBJECT視為不可變。不要給它任何識別碼，並避免為了維護ENTITIES所需的設計複雜性。

***

SERVICE

Forces:

• 領域操作（domain operations）本質上是活動或動作，而不是事物。
• 領域操作無法被歸屬於某個ENTITY或VALUE OBJECT的自然職責時。

Solution：在模型中增加一個操作，作為代表SERVICE的獨立介面。根據模型的語言定義介面，並確保操作名稱是UBIQUITOUS LANGUAGE的一部分。使SERVICE為無狀態。

***

以上內容大多出自藍皮書，Teddy只是把格式重新調整，抓出Context與問題。以後看到ENTITY、VALUE OBJECT、SERVICE，鄉民們第一個想到的就是「設計領域物件嘿用得到」（這是它們的Context）。接著問題就是有哪幾種領域物件的種類？依據不同的forces，可以分成三種不同的領域物件。

如果用這種方式去思考與記憶，Teddy覺得比較不會在藍皮書中所提到的一堆模式中迷路。

***

動動腦

同樣的內容，為什麼有些人可以用很有條理的方式讓別人聽懂，有些人卻講得非常冗長，讓人越聽越迷糊？！

模式的六大格式是一種很好的收納知識方法，鄉民們可以自己練習一下，找幾個DDD書中其他模式，把它們的問題、解決方案，以及forces抓出來。

練習過後會產生和吃「瀨尿牛丸」的效果，人都變聰明了！

***

友藏內心獨白：練習把飯菜裝進六個格子的便當盒裡面。

泰迪軟體2020年上半年開課時間表

Dec. 03 16:43~17:28

▲領域驅動設計與簡潔架構入門實作班課程照片 （原Clean Architecture實作班）

時間過得好快轉眼就要跟2019說Bye Bye，又到了年底排課表的時間。2020年Teddy預計新開一門【行為驅動設計與實例化規格實作班】課程，開課時間大約在2020年8月之後。

以下是泰迪軟體2020年上半年課表，原本的【Clean Architecture實作班】，因為課程內容包含許多領域驅動設計（Domain Driven Design；DDD），所以Teddy將課名調整成【領域驅動設計與簡潔架構入門實作班】。

Scrum敏捷方法實作班

• 假日班：2月22、23號（六、日）。
• 假日班：5月9、10號（六、日）。

看板方法與精實開發實作班

• 假日班：3月21、22號（六、日）。

Design Patterns這樣學就會了--入門實作班

• 假日班：3月7、8、14號（六、日、六）。

Design Patterns這樣學就會了--進階實作班

• 假日班：4月24、25、26號（五、六、日）。

敏捷開發懶人包：物件導向技能

• 平日班：3月24（二）。

領域驅動設計與簡潔架構入門實作班（舊課程名稱為：Clean Architecture實作班）

• 平假日班：2月14、15、16號（五、六、日）。

單元測試實作班

• 假日班：4月11、12號（六、日）。

例外處理設計與重構實作班

• 假日班：6月13、14號（六、日）。

軟體重構入門實作班

• 平假日班：4月17、18、19號（五、六、日）

▼看板方法與精實開發實作班課程照片

▼「單元測試實作班」課程照片。

▼「敏捷開發懶人包：物件導向技能」課程照片。

***

友藏內心獨白：2020年還請鄉民們繼續支持。

你也可以撰寫模式

Dec. 02 09:53~10:55

重複使用知識

11月30日Teddy辦了第一次一整天的【模式寫作工作坊】，六個小時的工作坊內容包含了：

• 介紹模式歷史與常見格式。
• 閱讀模式
• 寫作模式

Teddy發現對於第一次寫作模式的人來講，第一個遇到的困難點就是如何挑選寫作題材。模式的定義，可以簡單用以下一句話來說明：

模式就是在一個特定領域中，針對重複出現問題所提出證明可行的解決方案。

也就是說，模式不是創新，而是將已知可行且可重複使用的解決方案與其所要解決的問題記錄下來。因此，模式寫作可視為一種整理知識的過程。要寫出好的模式，最簡單的方式就是從自己熟悉的身邊事物開始著手。

***

生活觀察家

模式不限於軟體開發，而是可以很生活化，包含所有的領域。只要認真做事、認真過生活，便可觀察到許多有趣的模式。

例如，對於一個專業宅宅而言，每天在家裡關注不同的網路紅人與YouTuber，久而久之很容易察覺這個領域的常見模式。像是：

• 自己的定位：確定自己要當哪一種類型的網紅，例如知識性、網美、搞笑、旅遊等。
• 鐵粉：找到自己的定位之後，想辦法吸引一群死忠支持自己的鄉民。
• 人頭粉絲：有了基本盤之後，要擴大自己的網路人氣。此時可考慮廣納各方人士，增加自己的粉絲人數，壯大氣勢。
• 互相拉抬：與其他知名的網紅合作，增加彼此的人氣與粉絲人數。
• 系列故事：製作主題性的系列故事來吸引更多的關注者。
• 業配：「風蕭蕭兮易水寒，網紅一樣要吃飯」。為了讓網紅這個職業可以長久持續下去，可以考慮接業配增加收入。
• 安排好的偷拍照片：現在網紅這麼多，如何增加自己的曝光度？利用人們偷窺的好奇心，設計一些「偷拍自己的照片」，然後故意流出到各大社群網站，讓「小時不讀書，長大當記者」的朋友們幫你免費宣傳。
• 小鈴鐺：你經常發布訊息、照片或影片更新，但你的粉絲卻無法即時收到。請粉絲們按下「小鈴鐺」，以便收到你最新的訊息。

***

模式範例

接下來Teddy寫一個網紅模式給鄉民們參考。

安排好的偷拍照片

▲圖片來源在此

Context：你將自己定位為網美型網紅。

Problem：如何增加自己的粉絲數？

Forces：

• 你在知名社群軟體，例如IG與FB經營一段時間，定期發布自己的照片與短片。
• 你有基本的粉絲。
• 你不想花太多經費或時間。
• 你父母不是知名藝人。

Solution：拍攝自己的清涼偷拍照片，找人將其張貼在PTT、爆料公社等社群，吸引 無腦 媒體報導。

Resulting Context：大部分的人喜歡看美女/俊男，更喜歡看被偷拍的美女/俊男。套用本模式可在短時間內衝高自己的人氣，進而增加自己的 豬哥 粉絲人數。實施本模式的成本很低，只要自己願意，可以簡易套用。

但是，不可忽視鄉民的智慧。如果偷拍照片拍得太假，可能造成反效果，被鄉民貼上「假掰」、「做作」的標籤。

***

友藏內心獨白：模式就是有六個空格的便當盒。

透過協作產生敏捷需求

Nov. 26 17:48~18:35

不是需求

許多跑敏捷的團隊會使用user story（用戶故事、使用者故事）來表達「需求」，大家一般認為寫user story是Product Owner的責任，團隊只要照著user story所描述的內容就可以做出PO所希望的功能。

但實際上功能做好之後卻經常被PO要求改東改西，導致開發團隊抱怨：「Product Owner寫的user story太簡略，害他們不能『按圖施工，保證成功』，要不斷地重工」。PO則是不滿開發團隊都不動腦筋，遇到問題也不及時跟他溝通與釐清。

其實user story不算是傳統軟體開發所說的需求或規格，user story只是引發團隊討論需求的一句話。真正的需求，透過開發團隊、Product Owner與利害關係人的對話、討論、探索而產生。討論之後所產生的需求，可以透過specification by example（實例化規格）的方式記錄下來。

另外，撰寫user story的責任也不能全部推給PO。User story的「為了…（目的）」所描述的是使用者所遭遇的問題，這是PO需要負責搞清楚的部分。而「我想要…（做什麼）」這句話已經包含某種解決方案，則是需要PO與開發團隊一起討論，尋求各種可能的做法。

***

心態改變

上週Teddy在上【Scrum敏捷方法實作班】介紹user story的時候跟學員提到上述觀念，下課時有一位學員說…

以前團隊在product backlog refinement workshop的時候，我們都習慣要求PO要把user story寫清楚，如果有不清楚的地方，我們會責怪PO，覺得他沒有準備好就找我們來開會。但上完課之後，我才發現原來撰寫user story的責任不能完全推給PO一個人。下次再開refinement workshop，我會改變作法，多提供意見。

***

協作遊戲

敏捷開發是一種協同合作的活動，不是傳統瀑布式開發那種「透過文件溝通」的模式，更不是找個issue tracking system（議題追蹤系統）來「開票、領票」（分派、追蹤工作）。

只是做做敏捷的樣子，心態沒變，還是白搭。

***

友藏內心獨白：讓團隊每個人都動腦真的不容易。

Pattern寫作工作坊

Nov. 19 16:54~17:57

一起做功德

PLoP（Pattern Languages of Programs）是模式（Pattern）社群一年一度的聚會，在全球各洲都有類似的活動，在亞洲舉辦的PLoP稱為AsianPLoP。

AsianPLoP 2020 明年3月4-6日將於台北舉辦，這個活動往年都在日本東京舉辦，明年是第二次移師到台北來。因為Teddy的指導教授是活動主辦人之一，而Teddy也是模式的愛好者，利用此次機會跟AsianPLoP 2020的主辦單位「台灣軟體工程學會」合作，於今年11/30日在泰迪軟體舉辦一天的【Pattern寫作工作坊】，藉此活動讓更多鄉民有機會接觸的模式社群，從了解模式、閱讀別人的模式，進而能夠利用模式來整理自己的知識（寫作模式）。

本工作坊費用8,000元，由「台灣軟體工程學會」開立收據。所繳交費用可全額抵免明年的AsianPLoP 2020研討會費用。也就是說，報名此工作坊的學員本人明年可以免費參加在北科大舉辦的AsianPLoP 2020 （無論是否投稿，都可參加）。

工作坊已確定開課，對模式有興趣的朋友，歡迎一起來聽聽模式的歷史、閱讀模式、寫作模式。

***

Teddy的模式之旅

Teddy從1997年開始接觸到設計模式，當時讀了GoF的《Design Patterns》，實際應用之後覺得設計模式對於軟體開發很有用，但對於書中提到的23個模式也是一知半解。

幾年後回北科大念博士班，因為之前工作從事e-learning系統與數位教材製作工具的開發，對design patterns也熟，因此指導教授建議Teddy可以研究e-learning領域的patterns。因此，讀了pattern發明人建築師Christopher Alexander一系列的幾本書，同時也開始寫作e-learning patterns。在2004年時，第一次到美國參加PLoP，那時有種劉姥姥逛大觀園的震撼---原來這就是傳說中的PLoP啊。

這幾年Teddy建議不少人讀Alexander的書，但似乎效果不適很好。Alexander的書有點哲學的味道，剛開始不是那麼容易讀懂。但他的思想的確影響了很多軟體社群的人，Design Patterns、Architecture Patterns、Testing Patterns這些大家都耳熟能詳就不說了，最近1~2年在台灣流行的領域驅動設計（Domain Driven-Design；DDD），發明人Eric Evans所寫作的「藍皮書」，其實就是一本DDD Pattern Languages，書中介紹了數個DDD patterns。

▲「藍皮書」本身就是一堆patterns

***

有什麼用

PLoP研討會已經舉辦了20幾年，學習pattern不是什麼趕流行，而且坦白說有點門檻。對Teddy而言，pattern（特別是pattern language）的訓練有三個主要的好處：

• 讓人具備一種關照全面與看到事情本質的能力。學習pattern很重要的一環就是觀察Forces，體驗Forces。漸漸地，你更能關注事物核心的Quality，而不是表面的Name（因為Quality Without A Name）。
• 吸納新的知識：很多領域專家，會將他們多年累積的知識寫成pattern。對於真正了解pattern的人，就比較容易吸收這些以pattern所表達的知識。以DDD為例，Teddy很晚（2013）年才開始接觸，但因為Teddy的腦中已經內建 九陽神功 pattern解譯器，對於DDD的學習就比一般鄉民要來得容易與深入一些。
• 系統性的整理自己的知識與經驗。你覺得自己很厲害，好，然後呢？FB貼廢文、寫blog、參加社群聚會當講者，這些都很好。但，如果要更進一步挑戰自己，將自己的經驗整理成pattern是一個很好的方式。

***

報名

報名表單在此，錯過這次，下一次就要等……不知道有沒有下一次了。

***

友藏內心獨白：我以為畢業後就不用再寫pattern了XD。

學習DDD有感

Oct. 18 14:46~16:18

客戶的發問

昨天下午到客戶家介紹領域驅動設計（Domain-Driven Design；DDD），以及如何運用事件風暴（Event Storming）、Clean Architecture、TDD的工具落實DDD。

活動結束時有同仁問Teddy：「你演講中提到DDD的好處我們都可以理解，具體上有沒有什麼實際的經驗可以分享？」

***

第一次接觸

Teddy首先想起幾年前剛接觸DDD，讀到《Domain-Driven Design: Tackling Complexity in the Heart of Software》這本書的情景。由於多年來Teddy已經習慣物件導向分析與設計（Object-Oriented Analysis and Design；OOAD）方法，當時覺得DDD強調建立領域模型（domain model）這件事，和OOAD並沒有什麼不同。另外書中提到的ubiquitous language、bounded context等觀念，其實就是pattern發明人Christopher Alexander在《Notes on the Synthesis of Form 》與《The Timeless Way of Building》等書中所提到的設計方法。至於DDD的Tactical Design（戰術設計）所包含的entity、value object、aggregate、factory、service、layered architecture這些patterns，也不過就是物件導向設計中常見的作法。

結論就是，這本書稍微翻一下就沒再理它了XD。

***

第二次接觸

過了一陣子，可能是因為微服務（Microservice）流行的緣故，DDD也跟著流行起來，Teddy同溫層的「臉友」談論DDD的人漸漸多了起來。這也引起Teddy的好奇，想說光看《Domain-Driven Design: Tackling Complexity in the Heart of Software》可能不夠，又買了幾本DDD的書，花了不少時間用力讀了一下。此時對於DDD所提出的這堆patterns的內涵有比較完整的認識，但總覺得，要開發軟體我就用熟知的OOAD就可以了，找不到一個施力點來使用DDD。

***

第三次接觸

兩年前在指導教授的建議之下，Teddy停掉在北科大資工所兼任的「軟體生命週期管理」課程，改教「軟體架構」。當時剛好Robert C. Martin 的新書《Clean Architecture: A Craftsman's Guide to Software Structure and Design》 出版，Teddy就用這本書當教科書。兩年來為了學習與教學的目的，Teddy設計兩個不同的專案，用了好幾種方式來詮釋Clean Architecture的實作。後來發現搭配DDD的domain model、ubiquitous language、bounded context、event storming、entity、aggregate、repository、service、domain event等pattern，以及Clean Architecture，加上採用TDD/BDD/SBE的方式實作系統，可以很漂亮的串起這些軟體開發方法。

此時，Teddy才慢慢感受到DDD的威力，特別是ubiquitous language in code的實踐，對於軟體的開發與維護所帶來的好處。另外，aggregate與domain event的使用，讓系統模組自然支援現今主流的分散式架構，這是傳統OOAD方法需要特別而外去關注才做得到的地方。

***

第四次接觸

約一年前Teddy帶幾位研究生開發一個看板系統，當初一開始設定的目標是要採用Clean Architecture作為此系統的架構。隨著開發活動進行，慢慢發現使用到DDD patterns越來越多，像是原本Clean Architecture就很強調的domain model，以及DDD的ubiquitous language in code、aggregate、repository、service、domain event等。

多年來Teddy也帶過好多組學生開發軟體，每次都立下宏願，希望用畢生所學，讓學生可以開發出「高品質」軟體。坦白說，多年來這個宏願一直無法實現。一方面研究生時間不多，要修課、寫作業、過日子，而且每年都有學生畢業，真正有時間投入專案開發頂多就是一個寒暑假而已。

另一方面學生的軟體開發能力與經驗也不足，還在學習當中，不容易要求在短時間內就可以做出設計良好的系統。

但是，這次開發看板系統Teddy感受到一絲曙光。初期Teddy花了很多時間與學生code review，先確認他們的Clean Architecture沒有走偏（目前還是有點偏，但至少沒有歪的太厲害）。後來隨著一個個user story實作的機會，幫助學生認識如何落實domain model與ubiquitous language in code。Teddy覺得光是這兩點做到，再搭配Clean Architecture，整個軟體系統的可讀性提升好幾個檔次。

Teddy希望有朝一日能做到「即是是學生所開發的軟體，也能夠達到專業的水準」。

***

老外幫我們做實驗

Teddy後來告訴發問的同仁：「DDD外國外已經提出10幾年了，有很多老外已經幫我們做過實驗。落實DDD的難度相對而言是比較高的，但是一旦公司與團隊能夠掌握這項方法，以我切身的經驗，我相信可以讓軟體開發更接近『讓軟體變軟』這個目標。」

落實DDD除了技術上的門檻以外，還有一點非常重要，就是團隊中有沒有領域專家，以及這位（或這一票XD）領域專家是否願意與開發團隊緊密合作，採用迭代與增量的模式，共同建立軟體系統的domain model與ubiquitous language。

DDD的技術門檻，可以來上泰迪軟體的〈Clean Architecture這樣學就會了實作班〉補足。至於有沒有領域專家願意與團隊緊密合作，就只能靠緣分了XD。

***

放下偶包

整個學習DDD的過程讓Teddy有一個很深刻的感觸：「很多時候以往的成功經驗可能會阻礙自己學習新的事物。」OOAD太熟導致一開始忽視DDD、Waterfall太熟導致覺得敏捷無用、壓專案時程太方便導致沒有給團隊自主決定的機會、成功的大公司導致無法冒險也沒有容忍失敗的空間。

所以武俠小說裡面的橋段：「欲練神功，揮劍自宮」都是真的。

***

友藏內心獨白：該不會下一頁是不用自宮，也能成功吧！