以領域為中心的：線上房貸申請系統設計 use DDD
以領域為中心的：線上房貸申請系統設計 use DDD 前言 DDD 的出現，為的是解決軟體專案開發過程中，不同的專業領域 或 經驗背景、技術專家 與 領域專家 溝通時，你講的跟我講的可能不一樣！？或你講的，跟理解的，跟我想的可能不一樣？... 是的！軟體專案開發最擔心的就是如此，專案會失敗大部分的原因也可能是如此，也因此 2003 年左右，Eric Evans 提出了 DDD, Domain-Driven Design 的思想與概念， 需求內容 圖（一）、案例一：線上房貸申請系統 需求以一個〔線上房代申請系統〕為例，關於這個需求讀者可以參考筆者先前寫過的幾篇 DDD 與 c4Model 的相關 文章 ，是以線上房貸申請系統為例的，而在更早之前我撰寫過一個 決戰 OOAD 的線上課程 ，課程中我們只是以基礎的 OOAD 並搭配 MDA 為出發點進行設計，現在，我想改以 DDD 領域驅動設計的方式重新設計這個線上房貸申請系統，上過此課程的學員也可以重新再練習一次，並跟著同時學習 DDD 的設計方式，因為同樣以 MDA 角度為出發點來設計。 領域敘事 （Domain Storytelling） 這邊我習慣以領域敘事來描述領域專家的的需求任務，原因除了團隊與個人習慣外，無其他特別因素。 圖（二）、顧客線上申請房貸的領域敘事 DDD 與軟體架構設計 DDD 其實不管軟體架構設計的，原因稍後會提到，DDD 大致分為兩大部分，也就是『戰略（Strategic）』、『戰術（Tactical）』，戰略的部分主要在解決領域需求上，不同角色間的協作與溝通，盡量能說出共通語言，或者建立共通的語言，也是 DDD 一直強調的 Ubiquitous Language 通用語言，並以此為基礎來建立領域知識，因為不同領域（銀行／流通業／金融業...）總是有個領域的專業術語，而在分析解決商業需求時，使用大家都能懂沒有隔閡的語言來溝通相當的重要。 圖（三）、解決領域需求與建模 線上房貸申請系統的領域模型 在本篇文章中，我加入〔額度利率試算〕這個 Context，原因是它經過需求提煉的過程中發現是可以獨立開來的 Context， 因此直接拆另一個 Bounded Context，而根據需求，需求中銀行顧客可以到線上房貸申請首頁，使用網銀帳號或初次申請進行簡訊驗證後方可填寫...