場景： 對WCF服務使用分層方法：業務服務將域/ DTO對象返回給客戶端。仍在開發中，我們可以打破合同。設計服務對象的方法是特定的還是通用的？
人物具有名和姓。會員對象具有稅號和出生日期。這是因爲，在我們的域名中，只有會員獲得稅號和出生日期。當從使用這種結構的服務獲取數據時，清楚哪些屬性適用。
現在，我們介紹另一種具有用戶使用的服務 - 讓員工說。在此用法中，人物對象需要附加屬性稅號文件號和出生日期。
什麼是繼續進行的最佳方式？
1）將Person對象視爲通用Person幷包含所有屬性。這將人員映射到真實世界的人，不一定基於用法。這意味着返回人員的服務將包括稅號和出生日期，即使這些服務可能不相關。
2）將其他字段複製到Employee中。這使Person保持原樣，並且以重複爲代價保持特定的服務調用。
3）在我們爲Member和Employee繼承的名爲PersonWithDOBTFN的對象之間創建另一個。這消除了重複，保持特定的東西，但引入了複雜性。
我確實在尋找設計這些對象的最佳實踐方法。
您正在做什麼存在問題 - 在各種情況下都會出現問題。立即從你簡短的例子中，最明顯的例子就是如果一個人想成爲一名成員和一名員工。當一個人不再想成爲一名員工而是想再次成爲一個人時呢？
員工和會員不是真實的「是」的概念。我可能會「成爲」一名員工或一名成員，但這並不是我真正的自我，也不是我作爲一個實體的身份的基礎。會員和員工只是大量的兩個角色我們也在一個人的過程中佔據。
不要用繼承建模角色，它不能很好地工作。取而代之的是擁有Person並添加一個可以更改的Roles集合，支持一個人的多個參與等。
其餘的ehhh。映射它們邏輯上屬於的屬性，而不是基於某種策略或之前的操作過程。服務會返回任何您希望它們返回的內容，但底層數據結構應該合乎邏輯並防止重複。
我會受到誘惑去與
Person ---is-a---> Member ---is-a--> Employee
即假定有一些是在如何「僱員」的作品相比，「會員」是明顯不同的。在你的問題中沒有任何東西可以表明這一點，但我認爲會員沒有的員工中會有一些額外的功能。
關於你對複雜性的觀點，我會說在你設計的這個階段，這可能是你過早擔心的事情。對象層次結構的2個層次不僅僅不那麼複雜 - 如果嘗試分離邏輯，大部分體積適中的系統通常會有2個以上的層次。你關於複雜性的觀點是，隨着系統的發展，你應該考慮更多的東西，並且如果它達到了更復雜的水平，那麼這個問題就更復雜了。