發表文章

目前顯示的是 4月, 2021的文章

以領域為中心的:線上房貸申請系統設計 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,而根據需求,需求中銀行顧客可以到線上房貸申請首頁,使用網銀帳號或初次申請進行簡訊驗證後方可填寫