2023 DDD年會分享 總摘要
分享三個最有啟發的主題
前言
自己是個DDD的小白，在兩天的年會學到很多新東西，跟程式有關的，跟概念有關的，跟設計思考有關的，各種主題都有，皆從各個講者的分享中獲益良多。基於時間有限，且因應這次主題是「啟發」，分享3個為自己帶來最多啟發的主題。
主題的細節內容不見得是完全正確的，畢竟有些聽講是英文的，而且是靠著記憶回顧聽到的內容，在這樣「轉譯」的過程，有些內容可能已經失真，所以大家不用盡信以下分享的內容，將當作聽個概念就好。
重點 — Event Storming, 熵和計算耦合
Event Storming
第一個要講的是Event Storming，這也是跟我們開發人員比較有切身之感的主題。
這個大家應該都已經不只聽過，(公司)團隊的大家也實做過一遍了，因此細節在這邊就不多說。這邊有點像是為大家複習一下Event Storming的規則，以及講一些我自己的心得。
在做Storming的時候，姑且不論規則是誰來執行，我們寫的規則，理想上是要能「不插電」就能動。何謂「不插電」就能動呢? 是指不仰賴電腦等計算設備，靠著人也能將這個規則繼續正常運作下去。
比方說，銀行的轉帳功能，在電腦還沒發明之前，不也運作得好好的? 轉帳功能其中的規則，就是靠人也可以「不插電」去運作。我們今天使用電腦等電子設備，只是將這套規則易於「規模化」和「標準化」罷了。
因此，在Storming的時候，根本不用去想太多細節，不要被腦中想到的軟、硬體設備給限制住。
在做Event Storming時，其實一直想到以前上設計課的經驗。當時我們做的不是Event Storming，是拿便利貼在牆上，把使用者在特定情境下可能遇到的問題，整體流程「做個水平發想」。
剛剛提到的這個設計流程，就是「使用者流程地圖」或「使用者故事地圖」，跟我們做過的Event Storming有異曲同工之妙。
在還沒接觸到Event Storming之前，就覺得開發者應該要實際參與需求和流程的詳細討論，不然就是在設計師發想時，在旁邊觀摩與提問。
總的來說，其實蠻贊同開發人員透過自己的雙手，去把使用者行為事件逐步建立起來，而非等著設計師或需求方直接下達需求或規格，可以更「接地氣」地懂得每一步程式細節的建立，都是其來有自的。開發起來也更能貼近真實需求，更知道流程每一步都是怎麼來的。
熵與系統亂度
熵念做「商」，一言以蔽之，就是一個系統的「亂度」。簡單來說，熵越高，代表一個系統越亂，越不穩定。
而這又跟我們的程式或運作系統有什麼關係呢?
套用到我們系統來看的話，如果宏觀角度來看沒問題(運作OK)，微觀角度卻是不同的複雜程度，代表熵值有變高的傾向。
這樣說可能有點抽象，以下舉幾個寫程式時，可能會讓系統熵值變高的方法。
- 多了各種業務邏輯(sub domain)，在不同層(layer)的實作方法不同，就會在之後需要額外的時間去「查」。
- 有時候在UI層組裝業務邏輯，有時候是在db層組裝，導致系統的複雜度「分佈不均」。
- 該有需求都有（隨著需求的增加），但最後可能已經不敷使用，整個系統已經太過肥大了。
總結來說，隨著時間經過，熵值隨著「時間」增加，是無法避免的。換句話說，系統越變越複雜，同樣也是無法避免的。熵雖然是無法避免的變高，但我們要知道「為何變高」，靠著我們開發的「外力」，讓熵不會隨著時間變得太高，保持在「可控」的亂度之內，畢竟完全降為0也不太合理。
計算耦合
講者是「Learn Domain Driven Design」一書的作者，雖然只是短短45min的分享，但可以感覺得出他對於DDD領域的認識程度之深。
這次主要分享的是「耦合」，一開始就提到說，不是「零耦合」便最佳。過度解耦，只是把一坨大便💩，變成好多小坨大便 💩💩💩。程式的耦合適度就好，不是拆光光就是最乾淨。剛剛好的耦合可以讓邏輯更加緊密，也更好理解。
這場聽講中，我認為最核心的是講者提到評估「系統更改的耦合程度」的方法，也就是說系統更改一個地方，我們要花費的代價有多高，講者是以Cost Coupling命名這個耦合。
會以三個維度來綜合評估，分別是Strength, Distance和Volatility。
- Strength強度：假設有兩個組件（不管組件是啥），組件之間以「關聯與互相認識」在連接著；共享的「知識」越多（商業邏輯之類的），其強度越高，當然更改代價也是越大。
- Distance距離：離細節越遠，距離越長。距離越遠的更改，代價（cost）也越大。
- Volatitlity波動度：也就是更改的影響程度。通常越核心的功能，更改所造成的波動度也越大。
有個公式： Cost Coupling = 程式更改的苦痛程度 = Strength * Volatility * Distance
講者提到幾個可以讓這個苦痛程度降低的解法，就是直接從這個他提到的這個公式來解。我們可以這樣做:
- 只要其中一項是零，Pain就是0，所以試著決定「哪一項降低為0」。
- 盡量降低整合的 stregth(as much as possible)。
- 那如果系統的strength和volatility很高，也就是組件之間彼此有關聯，而且是核心功能，那麼就降低distance，讓這些組件的距離更近一點，細節更直接互相認識。
總的來說，就是在三者之間取其「輕」，做出取捨。
最後，最有印象的是聽眾的發問，有人問到說，該怎麼學好DDD。他回答道，他當時最快學會的方式就是做錯，做了很多嘗試，體驗了很多次的「失敗」，才從失敗中記取教訓，逐步在新的程式碼中實踐DDD，直到DDD的精隨深入骨子裡。