前一陣子，同人參與開發的專案有新需求要以業務單位關聯執行單位的地理區域。有別於一般人習慣的資料驅動編程（Data Driven Programming）的方式，同人採用領域驅動設計（Domain Driven Design）的方式，來設計並實作符合這項需求的功能。在過程中，我發現我分析出來的領域模型可以擴大它的應用範圍成為管轄區域的分析樣式。這個樣式適用於管理單位負責管轄區域內的管理，並指派執行單位來處理業務的執行。這個分析樣式讓人更深切地體認 Accountability 的分析樣式，同人想透過這篇文章分享我的心得與感想。
專案的需求是使用者希望可以選擇他可以挑選的執行單位，然後系統就會以選擇執行單位的管轄區域來篩選資料。這個功能如果以純粹資料驅動出發的觀點來看，應該會需要額外定義兩個資料表（Table）來表示管理單位對執行單位的一對多關連，如同下面這張概念圖所示：
但同人覺得上面的概念圖過於技術性，而且當中隱藏了一些重要的業務概念，溝通上將會因為牽涉到繁複的技術細節而產生障礙，於是同人從領域概念的觀點來分析，發展出業務管轄區域的領域概念模型。
上面的概念圖很清楚地呈現關於管轄區域的語意模型，顯示許多問題領域的基本概念，是在先前資料驅動編程的資料關聯之概念圖當中所看不到的。與一般問題領域常見的交易樣式（Transaction Pattern）不一樣的是，管轄區域的語意核心並不在交易的事件，而在於「地域」。因為管理單位和執行單位之間在未發生交易之前，是沒辦法硬套用交易樣式來表達它們之間的關係，而它們實際上確有真實的關係，也就是一般稱為 Accountability 的概念。其實交易樣式也是一種事件觀點的 Accountability，而管轄區域的分析樣式則是關於地域觀點的 Accountability，包括下列幾個基本概念：
- 管理轄區是較抽象的高層次管理區域，代表管理單位負責的管轄範圍。
- 管理轄區可以細分多個較為具體而明確的執行區劃，以用來表示管理轄區的細節。按實際需要的某些應用中，我們可能需要在執行區劃中加入一些限制條件，例如在便利商店商品運送的問題領域中，執行區劃可以加入像執行時間、路線、頻率或配別等限制條件。
- （一到多個）執行區劃可以被分派到一個執行轄區，由某個執行單位負責處理該轄區的業務執行。
- 每個執行轄區包含多個執行地理區域，（一到多個）執行地理區域由一個行政區域所代表。
不過雖然管轄區域不屬於交易樣式，但它的分析概念的手法和交易樣式其實根本相通。因為兩者都是源於 Accountability 樣式，所包含的概念不脫於人、事、時、地、物的一般化詮釋，在這邊關鍵的概念的在人、地、時，其它事、物的概念較不重要。在管轄區域分析樣式用到下面幾種手法：
- 角色：管理單位對管理轄區、執行單位對執行轄區都是角色的概念，其實角色正是個體的共通化概念，一般來說，很多事件或地域會對應同一個角色。
- 地域：管理轄區對執行區劃、執行轄區對執行地理區域都是地域的概念，也就是表達更明確的位置，一般而言，邏輯位置的抽象概念會包括某些具體的實體位置。
- 關連性：在資料驅動編程的概念圖當中，我們看到一個管理單位（隱含管理轄區）對應到多個執行單位（隱含執行轄區）。但對於一個執行單位管轄的行政區域而言，最複雜的情況是行政區域和管理轄區之間的關係是多對多關係，要表示這種關係我們需要多一個關聯表格來存放 n:m 的多重關係，否則就要對不同管理單位重覆建立多次相同執行單位和行政區域的資料。不過從管轄區域分析樣式的概念圖，我們剛好看到一個管理轄區對應多個執行區劃、很多執行區劃可以對應到同一個執行轄區，因此執行區劃正是巧妙地扮演關連表格的角色，讓管理轄區可以共享相同執行轄區的資訊。比起資料驅動編程的概念圖，執行區劃並非技術觀點考量的術語，而是問題領域觀點所能理解的概念，這使得人們在開發及溝通過程可以更為直覺。
其實以管轄區域分析樣式所發展的資料模型，並不會與資料驅動編程的概念圖相去太多，比較大的差別只在於是否考慮多對多關連的情況。然而經過領域概念分析的過程的好處是，讓我們可以用概念性的表達來略除許多不必要的繁複細節，展現出抽象思考的力量。當然它很困難，但它卻是做好系統分析不可或缺的能力，是值得投注心力學習的技能。
