2

我正在嘗試構建一個域模型,以允許我管理合同。如何在Fluent NHibernate中建立此對象層次結構而不違反DDD原則?

合同類是我聚合根,它有一個單一的財產,現在,這是評審。

審閱,在合同的情況下,每有一個屬性,它的父合同,第一個名字,姓氏和登錄。他們擁有這些屬性的原因是我可以讓用戶在合同中選擇他們想要的審閱者。

說我綁我的域模型的數據庫已經存在,而且它是我試圖延長遺留系統。

它有一個合同表及審閱表。

我沒有提到的,直到這點事情,是審閱實際上是系統中的用戶。所以實際上有第三張表,即用戶。

我已經能夠與FNH容易映射我的合同表。

它看起來是這樣的:

public class ContractMapping: ClassMap<Contract> 
{ 
    public ContractMapping() 
    { 
     Id(c => c.Id); 
     HasMany(c => c.AdditionalReviewers); 
    } 
} 

但我不知道怎麼我的評審模式,因爲它們實際上是用戶也是如此。所以,我的對象模型看起來是這樣的:

public class Reviewer: User 
{ 
    public virtual Guid Id { get; set; } 

    public virtual Contract Contract { get; set; } 
} 

public class User 
{ 
    public virtual Guid Id { get; set; } 

    public virtual string Login { get; set; } 
    public virtual string FirstName { get; set; } 
    public virtual string LastName { get; set; }   
} 

我已經能夠正確映射我的User類,它看起來是這樣的:

public class UserMapping: ClassMap<User> 
{ 
    public UserMapping() 
    { 
     Id(u => u.Id); 
     Map(u => u.Login); 
     Map(u => u.FirstName); 
     Map(u => u.LastName); 
    } 
} 

,我相信我要地圖我的點評類是這樣的:

public class ReviewerMapping: SubclassMap<Reviewer> 
{ 
    public ReviewerMapping() 
    { 
     Table("Reviewer"); 

     //Id(r => r.Id).Column("ReviewerId"); <- won't compile 
     References(r => r.Contract).Column("ContractId"); 
    } 
} 

所以我遇到的問題是這樣的:

日之間的關係e用戶表和審閱者表是一對多的。意思是,對於給定的用戶,可能有許多審閱者記錄。爲什麼?因爲用戶必須是特定合同的審閱者。但是,這會導致映射問題,因爲Reviewer的主鍵和我的用戶的主鍵是完全不同的值。

而且,因爲我使用審閱的方式,當我創建一個新的審閱,我真正想要做的是用戶與合同相關聯。我是而不是試圖在數據庫中創建一個全新的用戶。

什麼是正確的辦法,我映射審閱,知道在我的域模型是用戶的一個子類?

回答

1

我不認爲審閱應該從用戶在你描述的情況繼承。我會讓Reviewer類持有一個User對象(組合繼承)。

如果它可以幫助你更好地概念化,重命名審閱審查。這樣,您可以停止將其作爲用戶來考慮,因爲它實際上不是(您當前域中的多個審閱者可以是同一個用戶,這沒有多大意義)。

+0

我看到你在說什麼,但是我爲這個問題設定的域上下文邊界只能用一個合同來設置。在這種情況下,同一用戶不能有多個審閱者。這隻存在於我當前的域環境之外(因爲我正在處理遺留系統)。也許有一些關於域名上下文的問題,我從DDD的角度並沒有把握。 – Joseph 2010-09-13 18:44:15

+0

@Joseph問題:爲什麼不是每個合同都有一個用戶列表,而不是這個額外的Reviewer類沒有任何東西?如果它保留了信息,比如評論數據本身,那麼我仍然認爲將該類重命名爲Review,並讓它具有User作爲其屬性之一是對該域進行建模的正確方法。 – 2010-09-13 21:38:14

+0

一旦我開始下一個任務,它就會有額外的數據,這是爲了跟蹤系統中的用戶實際上將審閱者分配給合同。我花了一些時間思考這個問題,我認爲你的想法是正確的,但是對於我的域,我認爲將User類更改爲UserAccount類更爲正確,並且只保留Reviewer類。通過將其更改爲UserAccount,我認爲它可以闡明實際發生的情況。 – Joseph 2010-09-14 12:33:57

2

聽起來像一個審閱者並不真正建模一個人,但建模用戶的角色或分配。我會說你的領域模型在這方面存在缺陷。 Tweak Reviewer是用戶與合同之間的關聯類。

+0

我原來就是這樣,但我有一個名爲Reviewer的類,然後讓它包含一個屬於User的屬性,這似乎很奇怪,但從DDD的角度來看,這似乎是錯誤的。從DDD的角度來看,我需要我的合同才能夠添加審閱者並將其刪除。雖然,合同可以添加的那些審閱者是系統中的用戶。 – Joseph 2010-09-13 18:32:41