---
title: 'Domain Driven Design'
disqus: hackmd
---

# Domain Driven Design
Domain Driven Design 是基於領域專業知識來解決複雜商業邏輯的軟體開發方法論。

－DDD注重以下三個重點
跟 Domain Expert（專業領域專家） 合作並且定義出 Domain 的範圍及相關解決的方案。
切分 Domain（領域）為多個 SubDomain（子領域），並專注在核心SubDomain（子領域）。
透過一系列設計模式，把 Domain Knowledge（知識領域）注入到 Model（程式模型）中。

# Mircoservices and DDD
在 Microservices 剛開始紅起來的時候，很多團隊對其的看法是將每個系統中的 Entity 做成一個服務，每個服務應該只負責管理一個至兩個或是非常少數的 database tables。用這種方式設計系統的團隊，很快地就需要幾十個，如果不是幾百個的服務，然後需要在這些底層的服務上，加上第二層或是第三層的商業邏輯服務層。

在 DDD 的設計概念中，一個好的 Microservice 應該要完整的涵蓋，並只涵蓋某個 bounded context （DDD的名詞，可以想做是一個商業邏輯領域，後文會再詳述其在DDD方法論中的定義）。以電子商務的軟體來說，其中一個商業邏輯領域可能是 Shipment，另一個可能是訂單，這兩個商業流程和背後的軟體系統就可以也應該要分開。

# DDD API 規劃
業務需求：
• 一個叫做RestAirline的航空公司提供線上機票出售業務，用戶可以按照搜索條件搜索到所有可用的航班(trip)
• 當乘客選中一條可用的航班(trip)就開始了整個預定(booking)流程
• 一旦乘客選擇了一條可用的航班就可以修改航班(change trip)和選擇座位(seat)
• 當乘客選擇完座位還可以添加一些額外的服務，如：接送機服務(transfer service)等, 最後通過不同的支付方式完成支付(payment)
• 乘客在飛機起飛前，還可以做線上登機手續(checkin)並列印登機牌(boardingpass)，在Checkin的過程中還可以重新選擇座位
注意： 括弧中的英文術語可以理解為該公司的領域術語, 我們在領域建模的時候也會使用相同的術語，從而減少跟領域專家的溝通成本。
就上面的需求我們可以很容易的分析出若干個領域: Booking, Payment, Trip Avalability

POST api/booking/trip
GET api/booking/{id}
PUT api/booking/{id}/seat
PUT api/booking/{id}/flight


# 上課照片

# 實作範例
請參考:https://miro.com/app/board/uXjVPaV2--o=/?share_link_id=810827501827