Presentation Layer: 負責與客戶端發生互動
Application Layer: 負責協調UI與Domain Layer之間的互動
Domain Layer: 軟體的核心，所有相關的Domain information都在這，可以看成是Business Logic Layer，但不完全是
Infrastructure Layer: 負責各層之間的交互溝通、資料存取、安全性管理及通用Library
Presentation Layer
不該存在流程與規則，比如驗證規則，這是屬於Domain Object的工作; 比如工作流程，這是Application Layer要負責的; 比如資料存取、權限控管及例外處理，這是Infrastructure Layer的職責。
Application Layer
比較容易讓人產生疑惑的是Application Layer，接下來用一個實際的例子來說明。
使用者正在操作一套CRM系統進行客戶建檔作業， 這個作業將與客戶基本資料、關係網路、商機、交易記錄、合約等Domain Object發生互動關係，另使用者希望系統自動發送感謝Email給客戶，另外再發送建檔完成通知給所屬業務及業務主管，當使用者完成資料輸入，按下存檔，下一步系統該怎麼做? 這一連串的流程應該放到Domain Layer嗎? 還是Presentation Layer? 這時Application Layer就負擔起這樣的工作，它將協調呼叫相關的Domain Service、傳遞DTO及委託Infrastructure Layer執行Email發送。
在大部份的狀況，Application Layer有其必要性，但也有其不存在的時候，比如在Domain Model中存在一個簡單的公司通訊錄，提供給同事查詢，由人力資源部門負責維護這份通訊錄，當存檔時只會與同事基本資料這個Domain Object進行互動，那Presentation Layer只需要直接呼叫Domain Service，將DTO傳入就能完成，而不需要再建立一層Application Layer。
Domain Layer
非常重要的一層，包含了所有的Domain Model，整個DDD幾乎都圍繞著這一層，但並不難懂，DDD也提出了一些重要的元素，如Entities、Value Object、Repository、Service及Factories等等。
Infrastructure Layer
個人覺得這層很辛苦，它是做苦工的，跟Domain無關的所有雜七雜八的工作全都包了，在我們公司，這一層被獨立成一個Framework，由一個Team負責開發及維護，必須非常強調效能、安全及穩固性，因為它支撐起整個Domain Model及其他Layer。
DDD的四層式架構，每一層之間的責任劃分很明確，因此在撰寫程式碼時，就清楚的知道什麼功能應該放在哪一層，先不考慮重用的問題，重用是理想境界，畢竟現實世界裡有太多的需求在變化著系統，我們應該思考的是如何提高各層的內聚(Cohesive)，將程式碼放在正確的Layer中，當需求變化來臨，不會因混亂的程式碼造成系統愈來愈難以維護。