「ドメイン駆動設計　モデリング/実装ガイド」１章まとめ

1章　DDD概要

• 1.2 DDDとは

  • ソフトウェアを開発する目的は、ある領域に存在する特定の問題を解決するため。
  • このソフトウェアで問題解決しようとする対象領域をドメインという。
  • DDDはモデリングによってソフトウェアの価値を高める。
  • モデリングとはモデルを作成する活動
  • モデルとは何かは次の章で説明

• 1.3 モデルとは

  • DDD Referenceの定義を引用すると
  • 問題解決のために物事の特定の側面を抽象化したもの
  • ドメインモデル
    • ドメインの問題を解決するためのモデル。
  • データモデル
    • データの永続化方法（永続化方法の効率化という問題解決を行う）ためのモデル。

• 1.3.2 モデルの例

• 1.4 良いモデル、悪いモデル。

  • 1.4.1 良いモデルとは問題を解決できるモデル。
  • 1.4.2 良くないモデルの例
    • モデルが良くないと、実装がどんなに素晴らしくても問題解決ができるソフトウェアにはならない。
    • 1.5 良いモデルを作るには
      • ドメインエキスパートと会話する
      • 運用して得られた発見をモデルに還元する。
      • 最初からモデルは完成せず、徐々に改善して行くもの」という考えは DDD において非常に重要である
      • モデルを頻繁に更新したら、コードも頻繁に変更する必要があります。コードは、そのような変更に耐えられる実装でなければなりません。これは、ソフトウェアにとっては、実はとても高い要求になる。
      • それを達成するためのベストプラクティスが、エンティティやリポジトリといった戦術的設計パターン

• 1.6 DDD の問題解決のアプローチ

  • 1. ドメインについての理解を深め、モデルを継続的に改善する
  • 2. モデルを継続的にソフトウェアに反映する
  • この 2 つのアプローチが達成されてこそ、最終的に問題解決力が高いソフトウェアを実現できる

• 1.6.1 ドメインエキスパートと共にモデルを探求するとは？

  • 作って終わりではなく、一緒に考え続けるということ
  • ユビキタス言語
  • 発見したモデルの言葉を、すべての場所で使うという指針です。
  • 英語が有利

• 1.6.2 モデルからソフトウェアへの継続的な反映

• モデルを直接表現するコード

  • 極力モデルとコードの表現を近づけることを目指します。
  • DDD では、これを実現する方法にオブジェクト指向の手法を用いて実装します。

• モデル表現を隔離するアーキテクチャ

一般的なソフトウェアでは、モデルの表現以外にも、UI やデータベースとのやりとりといった処理が実装されます。これらの処理とモデルの表現を同じコードの中に混在させると、煩雑で記述量の多いコードになり、可読性、保守性が下がります。そこで、モデル表現とその他の処理をレイヤーという単位で大きく分離し、モデル表現を行う層を「ドメイン層」として隔離します。これを実現するための代表的なものに、レイヤードアーキテクチャ、オニオンアーキテクチャ、クリーンアーキテクチャがあります。

• 戦術的設計パターン

前述の通り、頻繁な変更に耐えうる拡張性の高い設計のベストプラクティスが、エン
ティティやリポジトリといった戦術的設計パターンです。
このパターンだけを取り入れることを「軽量 DDD」と呼ぶことがありますが、高い要
求を満たせるベストプラクティスを適用することになるため、設計/実装の改善には十分
効果があります。

• この軽量DDDはFlutterで知らない内にやってた。

しかし、ここまでに解説した通り、モデルが良くなければ実装が素晴らしくても問題は
解決できません。併せてモデリングにも取り組むことで、ソフトウェア自体の問題解決力
や価値を高められるのです。

DDD に関して良く目にする話題として、「モデリングしない軽量 DDD はダメなのか」
というものがありますが、決してそんなことはありません。軽量 DDD で設計を改善して
ようやく、モデルを改善する余裕ができる、と考えることもできます。
そして、戦術的設計パターンの適用とモデリングは両方同時に着手できます。設計の改
善にも、モデリングにも終わりがありません。片方を終えてからではなく、両方少しずつ
実施していくというアプローチが現実的でしょう。

• 1.7 DDDを取り組む上で重要な考え方

• 1.7.1 課題ドリブン

• 何かの意思決定をする際に重要なのは、解決したい課題を明確にすることです。これは、つまり「ルールで決められているからこう」という判断をしない、ということ

• 1.7.2 小さく初めて、小さく失敗する

  • 何事も、最初から正解に到達することはできません。実験して、そこから望む結果に近
    づいていくということが、現実的に必要なアクションです。

• 1.8

• 1.8.1 DDDの向き不向き

• DDD が向いているのは、問題解決しようとするドメインが複雑な場合です。複雑なド
  メインに対して、モデリングを中心としたアプローチによって問題解決力を高めたい、と
  いう場合には効果を発揮します。
  一方、非常にシンプルな場合 (単純な CRUD しかない場合など) や、コアコンピタンス
  が技術的な関心ごとである場合 (超高速処理が重要な場合など) は、DDD のアーキテク
  チャの実装上のオーバーヘッドに対して、得られるものが見合わないことがあります。そ
  のような場合は、DDD ではない別のアプローチを考える方が良いでしょう。