作者首先點出，一個大企業，裡面維護單一的專案是不可能的，也就是累積了或者同時會有好幾個專案在開發，也不是所有專案都使用OO或者DDD開發，也就是多種的可能性
然則使用Domain model，可以嘗試著去描述其他的部分，也就是domain model的本質上並不受限於任何程式語言風格，講求的是溝通以及理解
在整合的過程中，有三件事情是重要的
- 一致性以及完整性 : 所有開發團隊對於相關的部分必須有一致的認知，否則會造成一些整合上不可預期的結果
- 精煉 : 為了能夠掌握專案的目標，同時維護專案在可以理解的情況下，精煉、精簡出Core domain有其必要性
- 大比例架構 : 所有事情不是一步登天，做為指導原則作者提倡大比例架構，如果特殊化，在軟體上可以稱為Architecture
一致性以及完整性
一張圖道盡整個一致性以及完整性維護的地圖
Bounded Context : 將想要表達的模型，有範圍的規劃起來，並且給予有意義的名字，同時確保範圍內不會受到其他模型的影響。
Continuous Integration : 分布整合、自動測試、概念整合、model整合，尤其是自動測試，是一種快速檢視Context之間有沒有問題的技術
Context Map : 強調各bounded context之間的交互作用，可以思考SOA是如何運作
由上面三個主要元素，可以知道，在畫分完畢後，主要的問題將是context之間的介面
最常見的是介面/service之間的問題，是否由相同團隊開發?是否有權利要求提供介面?是否需要完成自己轉接介面(adapter)，而影響因素有溝通能力以及決定權
Shared Kernel : 共享的概念上子集，類似binary/source code等級的分享
Customer/Supplier Development Team : 上下游關係，如開發廠仰賴系統廠的功能，有分層的味道，兩邊必須要有適當的協調者
Conformist : 單純的跟隨者，例如開發廠完全無法要求系統廠提供任何支援性功能，那只有單純的跟隨
Anticorruption Layer : 透過實現特定層面(layer)，團隊自行完成上游所不提供，但自己所需的功能
Open Host Service : 經過一段時間開發，整合所有開放的service
Published Language : 透過一種標準，開放service，如SOAP
兩大因素與採用模式的關係圖如下
精煉
為了能夠集中精神在主要目標，以及提供能夠處理的內容，深入理解context之後，精煉出主要的模型是必須的，但也是費力氣的
Domain Vision Statement : 願景是很簡短且重要的
Highlighted Core : 從大量的背景知識中抽出重要的部分
Segregated Core : 將核心更加模組化
Generic Subdomain : 將支持性的模型移出core domain
Cohesive Mechanism : 讓domain集中在what to do不是耗費在解釋how to do
Abstract Core : 抽象畫主要設計
其中作者點出了很多的風險
其中作者點出了很多的風險
大比例原則
以architecture角度切入會顯得比較容易體會，但是architecture並不等於domain model，所以作者提供的觀點卻是更高階的
- evolving order : 概念上的模型必須隨著模型一直演變
- system metaphor : 適當的使用隱喻可以增加對系統的了解，比方說再architecture上說明是MVC
- responsibility layers : 模型對象往往已職責為依歸，仔細觀察這些對象的變化頻率以及職責所在，可以適當的aggregate以及module化
- knowledge level : 如果抽象對象之間的關係限制，無法完整描述，則應把限制這樣的知識暴露到domain model之中，作者舉例出，兩個物件，員工以及退休計畫，如果只有兩個對象，可以隨意匹配，然而某些員工只能享有某些退休計畫，所以把"員工種類的退休計畫"這個對象放入domain model來滿足
- Pluggable component framework : 從interface以及interaction中抽出abstract core的部份，並且建立一個框架，符合介面的元件都可以被抽換
作者再某一章節給出了顯示完整性、精鍊以及大比例原則之間的互動，同時顯示了一個範例如何借助DDD所有技巧發展出一個domain model
沒有留言:
張貼留言