DDD 簡介
我個人認為與其說 DDD 是一個技術的實作方式，比較恰當的是將其視為一個大型系統設計方法論和概念。就如 Agile 方法論 一樣，不論你是用 Kanban，Scrum 或是任何其他的方式，最重要的精神應該是持續的改善(Continuous Improvement)和快速的迭代(Fast iteration)，而不是死板的遵循其所提到的會議進行模式。
以 DDD 來說的話，如果你的團隊花了很多的時間爭論 Entities 和 Value Objects 的不同，和系統的某個值應該是 Entities 還是 Value Objects 的話，我認為方向可能就是錯了。系統的實作會隨著時間而改變，而技術的演進也會讓你的團隊從不同的方向來思考系統的開發。也因此你的團隊應該要注重在DDD 的概念，和用這概念來設計系統。
為什麼你需要 DDD ?
Domain Driven Design is an approach to software development for complex needs by connecting the implementation to an evolving model.
DDD 最能展現其價值的地方就是他的方法論可以被用來有系統地解構複雜的問題，而不是單純的就軟體設計來做討論。
DDD 很大的的一個部份是在討論商業，系統，使用者流程的分析，而不是技術面上的分析。而這也是，我個人認為，其最大的價值所在。在經過這個分析和設計之後，理想狀況就是，你的團隊可以用一樣詞彙來溝通，系統和團隊間應該有清楚的界線；而且，對你的每一個商業流程圖，你應該可以在你的資訊系統內找到相對應的功能和清楚的對應關係。
特別要提到的是，由於他的 Overhead（ 比如說，設計流程的繁複，你整個團隊必須對其有一定的了解），這套方法並不適用於所有的軟體產品。你如果是一個創業團隊，你絕對是不需要 DDD ，因為在創業初期，你的產品和軟體複雜度相對的簡單，使用這個方法論只會降低你的團隊產出。而且，在創業初期，很多產出的軟體經過 A/B 測試後會被下架，用這個方法論在不成熟的產品上，很多時候會是一個浪費。
Mircoservices and DDD
在 Microservices 剛開始紅起來的時候，很多團隊對其的看法是將每個系統中的 Entity 做成一個服務，每個服務應該只負責管理一個至兩個或是非常少數的 database tables。用這種方式設計系統的團隊，很快地就需要幾十個，如果不是幾百個的服務，然後需要在這些底層的服務上，加上第二層或是第三層的商業邏輯服務層。
在 DDD 的設計概念中，一個好的 Microservice 應該要完整的涵蓋，並只涵蓋某個 bounded context （DDD的名詞，可以想做是一個商業邏輯領域，後文會再詳述其在DDD方法論中的定義）。以電子商務的軟體來說，其中一個商業邏輯領域可能是 Shipment，另一個可能是訂單，這兩個商業流程和背後的軟體系統就可以也應該要分開。
另外一個使用DDD方法論的好處是清楚的定義公司和團隊的重點發展方向。在了解公司的運作和商業流程後，就可以進行 Domain types 的討論 (Core Domains, Supporting Domains 和 Generic Domains)，這也是一個很好的機會和公司的高層做策略上的調整的討論，你可以利用這個機會來確認公司現有對這些領域的投資，和是否需要調整資源的分配。並確認你和你的團隊時間和精力花在對的地方上。
接下來的文章，我會再討論 Domains，Bounded Context，如何進行 Change Management 和 User Interview，和其他 DDD 相關的方法論和實作上的問題。如果大家對這有什麼想法或是想要多瞭解哪一個部分，還請在留言討論！
