Tips_Of_Domain-Driven_Design

ドメイン駆動設計のTips

要件収集

「関数型ドメインモデリングドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう」

要件収集の際にはすべてを受け入れる姿勢を保ち、自分の技術的な考えをドメインに押しつけないことです。

要件収集時に頭の中でクラス設計をしてはいけない

ドメインの文書化

ドメインエキスパートにも理解できる内容を記述する
非プログラマを尻込みさせず、一緒に作業することを目指す

ドメインの記述

UMLは作業がしにくいため、以下のようなシンプルなテキストベースの言語で記述する

ドメイン境界: 注文

- ワークフロー: 注文確定
    - トリガー
        - 「注文フォーム受領」イベント
    - 最初の入力
        - 注文フォーム
    - 他の入力
        - 製品カタログ
    - 出力イベント
        - 「注文確定」イベント
    - 副作用
        - 注文確定に伴う領収書が顧客に送信される

データ構造の記述

ドメインのデータ構造を最小限の方法で記述する

ドメイン境界: 注文

data 注文 = 
    顧客情報
    送付先住所
    請求先住所
    注文明細リスト
    請求金額

data 注文明細リスト =
    商品
    注文数量
    金額

data 顧客情報 = ??? // 未確定
data 請求先住所 = ??? // 未確定

制約も表現する

data 食品系商品コード = "F" から始まる4桁の数字
data サプリ系商品コード = "P" から始まる3桁の数字
data 商品コード = 食品系商品コード or サプリ系商品コード

data 注文数量 = 個数 or 重量
data 個数 = 1以上の数値
data 重量 = 小数

ライフサイクルの記述

data 未検証-注文 = 
    未検証-顧客情報
    未検証-送付先住所
    未検証-請求先住所
    未検証-注文商品明細

data 価格計算済み-注文 =
    検証済-顧客情報
    検証済-送付先住所
    検証済-請求先住所
    検証済-注文商品 リスト
    請求金額 // 追加

data  検証済-注文商品
    検証済-注文明細
    小計 // 追加

data 確定済注文領収 =
    確定済-注文
    領収書

ワークフローの具体化

workflow 注文確定 = 
    input: 注文フォーム
    output:
        「注文確定」イベント
        or 注文失敗
    
    // ステップ1
    do 注文検証
    If 注文が無効 then:
        注文失敗を履歴に追加
        stop

    // ステップ2
    do 注文金額算出

    // ステップ3
    do 注文確定を顧客に通知

    // ステップ4
    return 「注文確定」イベント