身在軟體業,不斷推陳出新的技術框架都快把我們給淹沒。
但我相信軟體的本質還是在於「解決業務問題」的能力。
隨著業務的發展以及程式碼的增長,了解既有程式碼的業務邏輯比學新技術更困難,更別提要加入新的功能進去。
框架可以幫助我們免去技術細節,但同時我們也需要一種設計方法將繁複的業務邏輯清楚地實現到程式碼之中,因此出現了領域驅動設計 (Domain-Driven Design) 。
在本系列小弟將會為各位介紹這套在國外風行的設計方法,希望大家能夠打破「程式歸程式、業務歸業務」的迷思,一起學習寫出更易懂、維護的程式碼吧!
軟體架構淺談 在 Strategic Design 前往 Tactical Design 的路上,我們可以開始思考要用哪一種架構來協助我們達到目的。不過請切記...
DDD 架構: 分層式架構與依賴反向原則 相信很多人都有聽過 MVC 這類型的架構模式 (Architecture Pattern),這類型的模式在初期可以幫...
DDD 架構: 整合 Clean Architecture 前面學會了分層架構與依賴反轉原則後,其實已經可以理解流行的 Clean Architecture!...
DDD 戰術設計: Entity 概念與實作 Entity 給我定義定義 當我們與領域專家訪談需求時,總會有一些物件或概念常常出現,且需要有標誌來辨明其唯一性...
DDD 戰術設計:Value Object 概念與實作 前一篇提到,Entity 就像是我們故事中的主角,接著,我們來介紹配角:Value Object。學...
DDD 戰術設計:Aggregate 聚合設計 當我們的領域擁有越來越多的 Entity 與 Value Object,根據業務規則的需求,模型之間關聯性的複...
DDD 戰術設計:Aggregate 聚合設計 (續) 本篇我們將繼續介紹 Aggregate 的幾項設計原則,加深我們對於 Aggregate 在實戰上應用...
DDD 戰術設計:工廠模式 今天要介紹的工廠模式 (Factory Pattern),詳細的內容我就不再贅述。本次我主要關注的是如何在 DDD 中使用工廠模式...
DDD 戰術設計:Repository 資源庫 DDD 注重在 Domain 層的領域物件,而這些領域物件雖然擁有計算能力,但仍需要有持久化機制將他們存下來,...
DDD 戰術設計:Application Service 有了前面篇章對於 Entity、Value Object 以及 Aggregate 的介紹,我們已經裝...