Zenn
👌

[読書ログ]関数型ドメインモデリング - １章

2024/12/01に公開
関数型プログラミング
DDD
ドメインモデリング
読書ログ
関数型ddd
tech

[読書ログ]関数型ドメインモデリング

今回はこの本の読書ログです。

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

"関数型"と記載されてて難しいような印象を受ける(受けてた)が、
DDDの概要と設計の要点、テクニックについて紹介されている本です。

この本の軸はこの2つ。

  • ドメインエキスパート、チームメンバーとのコミュニケーションの重要性
  • 実世界の概念に基づいたドメインモデルが共有されることの価値

今回は１章の要点まとめをかいていきたいと思います！

補足: この本の構成について

構成

第1部：ドメインの理解

  • ドメイン駆動設計の紹介(ドメインのモデル化の重要性と、モデリングの影響について)
  • ドメインの分割と境界づけられたコンテキスト(コンテキストの概念)

第2部：ドメインの詳細

  • ドメインエキスパートからの情報収集の方法と、重要性について
  • 複雑なドメインの扱いについて (複雑さを軽減するための設計手法)
  • ドメインモデルのパターン
    (データモデリング、エンティティ、アグリゲートなどの概念とパターン、表現方法)

第3部：実践編

  • ワークフローのモデリング
  • リファクタリングと保守(リファクタリング手法)
  • シリアライズと永続化 (DBに永続化する際のベストプラクティス)

第4部：設計の実践

  • テスト駆動設計
  • パフォーマンスの最適化
  • 将来の拡張性

🚩 1部: ドメインの理解

📍1-1 モデル共有の重要性 -- "完全に理解した"のために...

本番環境にリリースされるのはドメインエキスパートの理解ではなく開発者の理解だということ

⭐️本来のドメイン駆動設計の目標とは

ビジネスドメインの本質に基づいて、柔軟で保守可能なシステムを構築すること
→ ソフトウェアモデルとビジネスドメインを一致させること
= 開発者とドメインエキスパートで共通理解を築くことが重要

ビジネスドメインとは:
ソフトウェアが解決しようとしているビジネス上の課題や対象領域,業務

ドメインエキスパート（業務の専門家）のメンタルモデルをコードに翻訳するが、
ドメインエキスパートと開発者の間に仲介が入ることでこの翻訳には歪みが生じる可能性がある.

ソフトウェアモデルとビジネスドメインを一致させることのメリット
  • 市場投入までの時間短縮
  • ビジネス価値の向上
  • 無駄の削減
  • メンテナンスと進化のしやすさ(モデルにドメインが集約されていてコード変更が容易)

📍1.2　ビジネスイベントによるドメインの理解

📝 ガイドライン①："データ構造ではなくビジネスイベントやワークフローに焦点を当てる"について

  • ビジネスは単にデータを持っているだけではなく、何らかの方法でデータを変換するから
    → ビジネスは連続的な変換の流れとして捉え、
    どのように機能し、互いに関係するかを理解することが大切.

ここで言ってる"ビジネス"とは：
価値を生み出し、提供するプロセス全体のこと

補足: "ビジネス"とは
  • ここで言ってる"ビジネス"とは：
    上記した通り、価値を生み出し、提供するプロセス全体のことだが、
    具体的には、企業の中で日々行われるさまざまな業務や取引、運営に関わる活動のことを指している。

EX.) ECサイトの場合：
「注文を受ける」→「在庫確認」→「発送準備」→「出荷完了」

  • これらの活動が連携して、顧客のニーズを満たし、企業が利益を得る仕組みが"ビジネス" で、
    ここでのポイントは、
    単なるデータの保持ではなく、データを活用して何かを「実行する」一連のプロセスに焦点が
    当てられていることだ。

▶️ ドメインイベントとは...ビジネスの流れを引き起こす重要な出来事

  • この出来事をトリガーとして、次のプロセスが開始され、ビジネスの価値が生まれるもののこと。
  • ドメインイベントは常に過去形で、「○○した」「○○された」と書かれる。
    きっかけとなったイベントは、変更できない事実だから　だ。

▶️ ドメインイベント探索方法："イベントストーミング"について

  • 目的：ビジネスイベントと関連するワークフローを発見するための共同プロセス。
  • 方法：ドメインの異なる部分を理解する様々な人々を集め、ワークショップ形式で実施。
  • 参加者：開発者やドメインエキスパートだけでなく、成功に関わる他の関係者も含むべき。
  • 進行方法：
    壁に紙やホワイトボードを貼り、参加者が付箋を使ってビジネスイベントを書き出し、
    議論や整理を進める。
    → 知っていることを書き、分からないことは質問するという形式(全員の積極的な参加促進)
    終了後には、多くの付箋が壁に貼られた状態になることが理想的。

参考文献：この手法の詳細はAlberto Brandolini氏の『EventStorming』が推奨

💡コマンドの文書化💡

"そのイベントを引き起こしたのは何ですか？"

  • この依頼を"コマンド"と呼ぶ。 (⚠️ OOPで出てくるコマンドパターンとは別物)
  • コマンドは常に"〇〇する"で現在系でかかれるもの。

📍1-3. ドメインをサブドメインに分割する

📝 ガイドライン②: "ドメインをより小さなサブドメインに分割する"

  • ドメイン内に特定の分野や知識が存在し、特定の領域（サブドメイン）として分けられることもある。
  • サブドメイン: ドメインをさらに細かく分割した領域
  • サブドメインは時に複数のドメインと重複し得る。

e.x) "CSS"で例えたら...
CSSは"webデザイン"ドメインの一部でもあり、"webプログラミングドメイン"の一部でもある。

→　現実は明快な境界値はつけづらく曖昧
しかし！！！！！！
ソフトウェアの世界では、別々のサブシステム(コンテキスト)の結合を減らし、
独立して進化できるようにしたい

📍1-4. 境界づけられたコンテキストを利用した解決手段の作成

▶️ 問題空間と解決空間について

  • 問題(ドメイン)の理解ができたら、その解決手段が必要だが、関連する情報のみを取り入れるようにしなければならない。

    • ポイントは問題空間と解決空間の区別をして異なるものとして扱うこと
      • 問題空間: 複雑な課題やドメイン。
      • 解決空間: ソフトウェア内で設計された解決策やモデル
        → 問題空間のドメインのモデルを作り、そこから必要な情報を抽出して解決空間に再作成する

  • 解決空間では、ドメインやサブドメインが境界づけられたコンテキストとしてモデル化され、
    特定のシステム内の役割を明確にする

▶️ 境界づけられたコンテキストの役割,利点

  • DDD（ドメイン駆動設計）では、各コンテキストに明確な境界を設け、異なるコンテキスト間での依存や相互作用を整理
    → ソフトウェア設計が 複雑にならないように する

    • 境界を意識することで、ドメインの重複や曖昧さを減らし、設計や開発が効率的になる。(問題を分離できる)
    • 境界内の課題に焦点を当てるため、解決策が効率的に設計される!

  • コンテキストを正しく反映することの重要性:

    • ソフトウェア設計の整合性を保つ
      → これにより、機能の重複を防ぎ、各コンテキストの責務を明確にすることができる

▶️ コンテキストを正しく区別する

→ ドメイン駆動設計の最も重要な課題の一つ。

ポイント

  • ドメインエキスパートの声に耳を傾ける
  • 既存チームや部門の境界に注目する
    →企業がドメインとサブドメインをどのように考えているかの手がかりになる。
  • "境界づけられた" を忘れない
  • 摩擦の少ないビジネスワークフローを目指して設計する
    → 複数のコンテキストで相互に作用してワークフローが遅延する場合、
    コンテキストのリファクタが必要。

"どのような設計も静的ではなく、ビジネス要件の変化に応じてモデルを進化させる必要がある"
→ もっと後章で解説

▶️ コンテキストマップ: コンテキスト間の相互作用を伝える方法

上記のように、コンテキストを定義したあとはコンテキスト間の相互作用を伝える方法が必要。

  • このコンテキストマップの役割は、
    様々な境界づけられたコンテキストのその関係性を詳細までではなく、システムの全体を示すこと。

  • この中(ドメインを扱う中)ではコアドメインの存在も明確になってくる
    → ビジネス上の優位性もをちお金をもたらす部分のこと。

    • コアではないドメインのことを"支援ドメイン"
    • 企業固有のものでなければ"汎用ドメイン"

  • 実装ではこのように優先順位をつけて最も価値のあるコンテキストから拡大する

📍1-5. ユビキタス言語 -- コードとドメインエキスパートは同じモデルを共有 --

  • 設計に存在するものは、
    全てドメインエキスパートのメンタルモデルに存在するものと同じ    である必要がある。
    → 逆を言うと、ドメインエキスパートの表現していないモデルを設計の中に含めるべきではない。

Discussion