Series
領域驅動設計
書本連結 前言 會挑這本書看的人，應該都是關心自己負責專案的軟體架構的人。不只希望開發的軟體能滿足客戶的明確需求，也希望能滿足可維護性（maintainability）的隱性需求，以及自己對結構與美觀習慣的要求。 要能滿足上述這些要求很難，因為專案通常不會按照計畫進行。可能變因有 deadline，最後的 API 與承諾的不同，又或者我們的設計無法很好的貼合需求的變化所需。。因此完美的架構只有在一
https://learning.oreilly.com/library/view/implementing-domain-driven-design/9780133039900/ch04lev1sec4.html#ch04lev1sec4 訪問 CIO 了解系統架構演化的過程與面臨什麼事件因此需要演化。 主持人 Maria 與 SaaSOvation 的 CIO Mitchell 對談，回顧十年來他們如何在不同階段選用合適的架構、搭配 DDD 而穩健成長。 早期：原本規劃桌面部署＋中央資料庫...
領域專家（Domain Expert）是了解特定問題領域（Problem Domain）並能運用解決方案領域（Solution Domain）處理問題的人士。他們具備該領域的深厚知識和技能，能夠精準地把握該領域中的關鍵問題與挑戰。因此，領域專家被認為是該領域的權威，能夠提供具有洞察力的見解和導引。 例如，法律顧問即是一種領域專家，他們精通法律知識，能夠快速瞭解客戶所面臨的問題，並且能運用法律相關流程，如訴訟等，來解決問題。每個人在學習和工作的過程中都有機會累積領域知識，並在該領域中成為領域專家。...
領域（Domain）可視為一個專注於特定主題、概念、技術及方法的特殊知識或專業範疇。這些領域可能涵蓋學術範疇，如數學或物理學；也可能是專業範疇，如醫學或工程學；甚至是產業範疇，如金融或零售等等。每一個領域都有其特有的知識和技能要求，以及各自需要解決和挑戰的問題。我們將這些特定領域的知識和技能需求稱為領域知識（Domain Know-how），它包含對該領域的基礎概念、原理、理論以及實踐方法的全面理解。 例如，實體零售業需要關注的問題可能是存貨管理、價格策略、供應鏈營運、消費者行為預測等，這些是零...
研究 DDD 的過程，有發現蠻多東西都非常抽象。 此系列文，是在解釋這個神秘的主題。 參考資料 Domain, Subdomain, Bounded Context, Problem/Solution Space in DDD: Clearly Defined
