領域驅動設計: Community discussion and Personal understanding

Service

Service曆來是爭論的焦點. 批評者認為Service的存在表明了職責的不清晰, 認為Service裡的代碼是沒放對位置的代碼, 都應該放到相關的Domain對象如Entity中. 總而言之Service不夠OO. Service是Transaction Script. 事實上這未必是Service這個building block的問題, 而是傳統的物件導向編程範式的問題. OO長於表達行為, 但局限於單個對象. OO在捕捉對象間的互動方面, 並沒什麼有力的指導原則. 比如, 當在儲蓄賬戶和信用賬戶之間轉帳的時候, 我是在儲蓄賬戶上定義轉出呢, 還是在信用賬戶上定義轉入?

有人認識到了OO的這種缺陷, 試圖將互動作為系統概念的一等公民, 與資料等並列, 比如DCI(DataContextInteraction)這種新的範式. 我覺得可以把DDD裡的Domain Service作為DCI中Interaction的實現方式.

既然是互動, 命名上就應該是動詞. 比如應該是TransferService, 而不是AccountService. 這樣更具體的命名可以避免Service通常帶來的另外一個問題: 因為名字太過General, 導致越來越多但凡沾點邊亂七八糟的代碼都往裡放, Service成了垃圾箱.

簡單一點就是:Action/Interaction 未必是某個class的method，也可以（並且更多情況下是更好的選擇）是一個單獨的class只帶一個execute方法. 這不只是簡單的代碼層級的不同，而是業務概念的顯式表達和隱式表達的區別, 尤其是當這個action涉及多個業務對象的時候, 放在哪個class裡也不合適. DCI也是這麼看的.

 

Application Logic vs. Business Logic

應用邏輯與商務邏輯. 商務邏輯是當你不用軟體而完全手工人工來完成業務時依然存在的邏輯. 應用邏輯是當你用IT系統來最佳化你的業務時額外引入特定於你當前軟體實現的邏輯. 保持這兩部分的分離有助於保持核心商務邏輯模型和代碼的穩定性. See<<領域驅動設計: More Practice>> for more details

 

Value Object

通常是Immutable的.這樣你就不用考慮是Copy還是Refer, 是存個Snapshot還是保證Up-to-date. 你只能換掉它而不是改變它. Value Object 不是 DTO, 它們是完全不同的概念服務於完全不同的目的, 只是湊巧有時實現看起來相同:

In general I'm not fond of DTOs since they provide no additional meaning over pure data structures. In most cases I prefer keeping DTOs outside the domain. -- from ddd google group.

 

DoD (Duplication over Dependency), RoR (Replication over Reuse)

這裡說的是Bounded Context. 在同一個Context內部, 我們不會容忍重複. 但不同Context之間, 有時重複是解依賴的手段. 更根本的原則是, 當重複出現的時候, 我們需要搞清楚它們概念上是否就是一回事, 還是兩個不同概念只是偶然實現在目前相同.

這裡還有很多沒想清楚的.

 

Entity + Repository = Active Record

如果把Entity和它的Repository放在一個類裡實現就跟Active Record看起來類似了. Repository負責集合操作

 

Query over physical collection

用查詢來實現集合, 可以lazy load, 可以解決循環參考. 這個其實跟DDD無關, 只是應用ORM架構時對performance問題的solution.

 

Layered Architecture

這裡不是說UI/Domain/DataAccess, 單就模型本身也可能分層. 模型反映解決問題的思路, 但對問題直觀的理解和解決往往隨著細節的深入而出現各種變化, 對此, 模型可以有不同層次. 高層的模型表達高層的解決方案, 很可能寥寥幾個介面和概念就足夠; 底下的層次則對應反映深入的問題

 

From DDD google group discussion:

Context

As a point to start to discover the contexts I often look to the organization chart of the company to see which kind of roles/point of view they have. The areas that you identified could be contexts.

 
Aggregates

Aggregates can be used as a technical tool or a modeling one.

• As atechnical tool it cope with limits of OR/M and the so in persisting and retrieving objects efficiently.
• As amodeling tool it cope with entities that contains other entities in the modelled domains (that are quite rare, if you consider that an entity is something that is identifiable by domain expert). the state of aggregated objects can be changed (or observed) only through the aggregated root object.

Aggregates are about controlling consistency and invariants, not about restricting the use of types.

 

Technical vs. Non-technical

• Parts of DDD that are non-technical, which in my opinion are the most important
• Howerer, the most expensive errors I have experienced are not related to technical details get wrong (we have very high skilled devs and archs), but in non technical decision taken too hurriedly. These "conceptual aspects" of DDD are the more risky ones. 
• ...(ddd) but it is little related to technique, but learning and understanding, exercise and practise: improved communication through the ubiquitous language,reduced complexity and added flexibility

 

Transaction Script vs. Domain Modeling

By using DDD we are turning the focus away from technical concerns and instead focus our effort to the business domain. I think TransactionScript have their proper place and use, but implementing them in a way mixing business logic with technical concerns is never right. Hence "undisciplined".

In this project I've heard people complain about different things they think is complex. Those people being unfamilliar with DDD but having a long history of working on the system thinks the TS code with mixed concerns and very few abstractions is fine since they see exactly what is going on and they "know" what the context is and how everything works on a detailed level. And they think the DDD approach of separating things into different layers and building abstractions for business concepts just adds complexity. Then we have the newcommers, that don't have any prior DDD-experience either, that struggle with understanding of the domain. Even though DDD is new to them they pretty quickly pick up on the concepts and think it is a great help in understanding the domain. To them it is the TS code that is most complex since it doesn't make any difference between lines of business logic and those of database interaction

 

Utility API for specific usage scenarioThe model is the core of the application, not the application itself. If you try to model a domain with an api that mimic the applicative context that will use the model, you poison the domain itself. Actually this was another thing that we learnt the hard way: at first, modelers did add methods (or even extension methods) to entities with the desire to help the application developers. But such helpers, turned to be a source of confusion, unnecessary dependencies and rigidity. Thus the signature you suggested could be useful for some clients of a service using the domain, but such async service api would work like an adapter, a façade to the model itself.