在上一篇DDD簡介和為什麼你需要DDD文中，討論了 Domain Driven Design 可以在軟體設計上扮演什麼樣的角色。接下來要談到如果你要應用Domain Driven Design來思考軟體的架構和設計的話，如何來進行第一步呢？
首先要講的是，DDD很大的的一部分是了解問題，商業模式，和公司的運行。你可能會覺得這部分的了解不重要，或是這些跟技術和軟體設計不相關。但其實這才是你最應該花時間的地方，以確保技術的投資和系統的設計是符合公司的大方向策略的。如果你還沒有對公司的策略和方向有很好的了解，我會建議在你開始實作 DDD 之前，可以用商業模式圖（Business Model Canvas）去了解你的團隊和商業模式。
商業模式圖與公司運作
了解流程背後的商業意義能夠讓你在跟領域專家（domain experts）討論時，更能夠有深入的討論和提出改進的建議。
商業模型圖是一個很好的工具去了解你公司的商業模式，如果你所負責的系統是公司某個部門內部的系統的話，你也可以用商業模型圖去進行針對該部門的分析。或若你是為非營利組織設計系統，你也可以商業模型圖作出修正後（比如說這個 Mission Model Canvas），做類似的分析來幫助你了解組織到運作。
在你了解你的團隊的商業模式後，下一步便是正式的開始做 DDD的分析。
DDD軟體設計的策略邏輯
“ Ubiquitous Language is a defined language that is used consistently across business and technical contexts”
首先，DDD 並不是要求你的團隊去使用某些 Patterns （event sourcing, repositories patterns），他著重的是如何解構一個複雜的問題，將問題變成數個小的問題，並有效的將其解決。而 DDD 有三大策略邏輯必須要先了解：
- 第一，與各你公司各個領域的專家（Domain Experts）合作定義領域模型（Domain Model）和各個領域的領域詞彙 （Domain Terms）。你如果有涉略DDD的話，你應該會有聽過 ubiquitous…
