2012-06-03 37 views
1

到域驅動的開發專家那裏...這是域驅動設計嗎?

我想要真正把握DDD的概念。到目前爲止,我一直在設計我的模型是數據驅動的而不是域驅動的。我已經閱讀了幾篇有關DDD的文章,並且看起來非常有趣,特別是對於大型應用程序。所以我正在試圖調整我的模型來做到這一點。

我不得不說,暴露出這將禁用所有客戶賬戶的方法FreezeAccounts客戶實體。此方法不涉及數據訪問(基於持久性忽略規則)。它更新每個客戶帳戶(按需加載)上的標誌並將更改保存到數據庫。這是正確的基於這種模式?我已經讀過,在DDD中,每個表實體不一定只有一個類。這個功能應該在一個單獨的類中嗎?下面是一些示例代碼:

public class Customer : ICustomer, ICustomerAction 
{ 
    #region Initialization 
    public Customer() 
    { 
    } 

    internal Customer(ICustomer view) 
    { 
     this.CustomerId = view.CustomerId; 
     this.Name = view.Name; 
     this.Email = view.Email; 
     this.IsActive = view.IsActive; 
    } 
    #endregion 

    #region Instances 

    private AccountCollection _accounts; 

    #endregion 

    #region Properties 

    #region ICustomer 

    public int CustomerId { get; private set; } 
    public string Name { get; set; } 
    public string Email { get; set; } 

    #endregion 

    #region Derived 

    public AccountCollection Accounts 
    { 
     get 
     { 
      if (_accounts == null) 
       _accounts = Account.GetListByCustomerId(CustomerId); 
      return _accounts; 
     } 
    } 

    #endregion 

    #endregion 

    #region Methods 

    #region CRUD 

    // Data Access Object accepts interface ICustomer 
    internal void Update() 
    { 
     CustomerDb.Update(this); 
    } 

    #endregion 

    #region ICustomerAction 

    // Exposed business Persistence Ignorance action 
    internal void FreezeAccounts() 
    { 
     foreach (Account account in this.Accounts) 
     { 
      account.IsEnabled = false; 
      account.Update(); 
     } 
    } 

    #endregion 

    #endregion 
} 
+1

現在一切都很清楚。我的例子是遵循傳統的活動記錄模式,而不是DDD。業務對象正在與存儲庫進行交互,而不是使應用程序服務與存儲庫和域(服務/實體)交互。關鍵詞:工作單元,實體根源和服務幫助清除圖像。謝謝! – fips

+0

那你爲什麼不接受正確的答案? :-) – inf3rno

回答

2

首先,在DDD在其他架構,數據訪問層必須從域和業務邏輯分離,所以沒有CRUD操作進入實體。

所以要回答,是的,創建一個單獨的層(不僅僅是一個類)來讀取/寫入存儲中的數據,特別是在DDD中,您可以使用Martin Fowler的RepositoryUnit Of Work模式。

如果你想DDD的例子看here

注:我將發佈的NuGet我DDD架構「視圖」的一個新版本。

+0

感謝您指出,完全同意單獨的數據訪問層。 CustomerDb.Update已經是用於數據訪問的不同類(DAL),ADO.NET/LINQ中的參數傳遞(使用接口很容易插入),所以Customer類(BLL內)只調用其方法「Update」,它接受一個類型參數ICustomer。我爲自己的代碼生成器編寫了常用層,MVC,會話Facade,BLL和DAL以及單元測試。我關心的是真正理解以數據爲中心和以域爲中心的體系結構之間的差異。有趣的文章,期待你的修改。 – fips

-1

隨着DDD你想保留什麼是實體清醒的認識(具有唯一的ID,並堅持作爲一個單獨的單元),什麼是一個實體根(要暴露給外部世界的實體) ,什麼是服務(管理實體間交互的代碼)。

項目在數據庫中的持久性如何與其實體對象完全不同 - 但由於您只處理實體,因此外部世界不必擔心這一點,並將其抽象到DAL。

在你的例子中,你正在很好地利用編程接口(我是SOLID),這很好,但是不知道系統的意圖,很難說這個示例是否遵循DDD。