先來看看目前我們專案的資料夾結構：

前面有提到，ActiveRecord 所建立的 model 與 schema 會直接互相綁定，要擺脫這個限制、重新建立 domain 中的 aggregate ，就需要額外處理資料存取的問題，因此在 domain 中大致上可以分成兩層，一層是資料存取層 Data Access Layer (後簡稱 DAL)，另一層則是領域邏輯層 Domain Logic Layer。至於 view 和 controller 因為不屬於業務邏輯，因此不會放在 domain 資料夾內。

註1:
這邊分層的名詞是我和同事在討論時約定成俗的共通語言，不一定為專有名詞
註2:
顯示邏輯要放在 domain 內或外在團隊內部也還沒有定論，因此先不放

Data Access Layer 資料存取層

包含 models 和 repository內的所有東西。

DAL 層負責提供一個穩定的介面，處理對資料的 CRUD，使領域層可以不用在意底下的實作方式。在 domain 中只有這層會與外部介面耦合，資料的異動僅能透過 repository 來處理。

Domain Logic Layer 領域層

包含 entity 和 use case。

DLL 層負責處理業務邏輯，視為整個專案中最核心的地方，因為他提供真實世界中的需求解決方案，因此這層最需要測試保護，也是含有最多領域知識的地方。

client 和 listener 是用來處理不同 domain 之間的依賴關係，往後會有專門一篇文章做討論。

本系列文章中所舉的例子，資料存在資料庫中、且使用 ActiveRecord 當 ORM；但其實 ORM 和資料庫對此架構來說，都是外部介面，因此假設今天儲存資料的地方是 local 的 csv 檔、或用另一套 ORM 系統，都一樣可以套用此架構。

下一篇會介紹失去了 model 這個物件，要用甚麼來取代他，以及我們在實作上的原則。