當面對大型專案，往往會因為最後無法好好運用這些分析出來的物件關係圖來套用在程式設計上，而得出結論：「以概念為基礎的物件無法作為程式設計的基礎」，那對於複雜領域的程式設計，我們就真的束手無策了嗎？ 模型與程式如何綁定？ DDD 要求同時模型協助初期的分析，也要成為設計的基礎，以 Model-Driven Design — 模型驅動設計為例，此設計方法強調模型需要同時反應 …

在沒有處理服務生命週期、監控、tracking 的知識或手段的情況下，這些問題會比使用單體服務來的放大許多，所以現在透過閱讀這本書來反思微服務的本質。 具有獨立生命週期的服務越多，必須處理的問題也越多 微服務到底多小好？ 服務多小才算夠小？我可以提供另一個陳腐的答案是，夠小，而不會更小 之前曾串接簡訊服務來驗證用戶手機號碼，為此我們特地製作一個微服務，功能只有兩個簡單的接口像 …

領域模型不是馬上可以得到，需要透過反復的知識消化（knowledge crunching ) 來提煉 領域模型的基本特性： 反應深層領域知識 (1 )領域知識間如何組織( 2) 重要元素的區分方式 聚焦於關鍵概念 Domain-Driven Design 跟 Object Oriented Design 有什麼不一樣？ DDD 重視的是整個設計流程，以領域模型作為開發基礎: - 團隊的共同語言 - 領域模型需要反復的精煉，但不一定是透過迭代開發/ XP開發/敏捷 OOD 則是在說對一組邏輯以物件的方式設計其特性和行為。 領域模型建立成功的要素 模型與實作的綁定：一開始簡陋的 prototype ，以及後續的持續維護。 建立一模型為基礎的語言：可以用模型中的術語來組成完整邏輯的句子，就像任何一個學術科目都有精準定義的術語，好用這些術語來表達通用的理論。 有豐富知識的模型：有點像某些 OOP 設計原則/概念：(1)充血模型 (2)高內聚。

看到 stepped leader 這個術語被小說《無職轉生》拿來用在強度的階級劃分上，引起了我的好奇，覺得小說作者真的不簡單，需要各項領域的知識加上創造力，才能將世界觀的設定完成，以下開始解說什麼事階梯先導 這個詞彙在氣象學領域使用，指閃電中的最一開始的放電過程，在小說裡用來比喻組織中有實力者組成的幹部，閃電其實是一個很複雜的過程，每個步驟都只在幾毫秒完成： 一次閃電是由多的閃光組成 Flash = many stroke One Stroke = leader process ( predischarge ) + return stroke 而 leader process 大致分為兩種： 1. stepped leader 階梯先導 — 每個flash 的 first stroke 中的 leader process — 速度較慢放電較大，會產生一階一階的階梯往下延伸 — 長得像階梯的原因是因為是由非常多的電崩潰（electrical breakdown）所組成，每個階梯都促使周圍的電荷更加活潑，因此產生下一階的階梯 2. dart leader 快速先導 — 第一擊之後的 leader process — 會沿著第一擊建立好的通路進行，所以需要的電量也較小

在經歷放棄創業之路之後，重新審視了自己在這條路上所欠缺的某些信念與原則，才在受挫時搖擺不定，最終放棄，也因此決定先轉換跑道，希望以不同的角度來實踐自己的人生與觀察企業的運作。 在工程與人生上有著某些相似之處，蓋房子需要符合安全結構的設計原則以及規範才能安全又富有創意，寫程式有某些設計原則與撰寫規範才能確保程式的正確性以及快速的迭代，而人生則需要原則來規劃人生、使用規則來避免風險與快速修正錯誤。 在這段時間的觀察，我發現人沒辦法把事情做好的原因，是因為對某些原則貼上了「沒用的雞湯」的標籤，但是當你詢問他同不同意時，他卻也認為是正確的，這樣的行為不連貫，導致停止自身的反思，也停止了成長，這點同樣也發生在我自己身上無數次。 有時，在不分輕重緩急，與不適合的場景下使用了原則或規則，而導致失敗而錯誤地認知為這些都是沒有用的雞湯，所以遇到許多挫折的我們會就算認同這樣的思想，卻也不得不迫於現實放棄。 原則

前言 一開始只是想做一個Golang的遊戲Server，既然是選用Golang當然免不了有點想試試新東西的想法，所以也使用gRPC作為遊戲封包的傳送，那做遊戲最簡單入門又跨平台的當然是選Unity了！就這樣我踏入了一個一個的深坑ＱＱ 由於gRPC對Unity的支援都還是非正式的狀態，有許多bug，發現的時候使用gRPC的Server都寫好了，只好硬著頭 …