「わかる！ドメイン駆動設計〜もちこちゃんの大冒険〜」を読んだ

programming

わかる！ドメイン駆動設計〜もちこちゃんの大冒険〜を読む。 社内のアーキテクチャや設計はDDD的な要素が入っているので知らないままではいられない。

DDD

DDDでやること

  • 開発者とドメインエキスパートがドメインモデルを作る
    • ドメインとは、ソフトウェアを適用する対象領域。
      • e.g. 会計ソフトならドメインは会計業務、など
    • ドメインエキスパートとは、その業務に最も精通した人
      • e.g. 業務知識に長けた人、業務の流れについてよく分かっている人、営業担当
    • ドメインモデルとは、業務ドメインに特化したソフトウェアモデルのこと
      • 業務は目に見えるものだけでなく概念や関係性なども含まれる
        • e.g. 役割や権限などは概念
      • ドメインを反映したモデルとは、ドメインを構成する物・概念・振る舞い・関係性を表現したもの
        • これらのドメインを構成する物・概念・振る舞い・関係性を表現したものは、開発者に対して明白になっていることは殆ど無い
        • 下記2つのプラクティスを実現しつつ、開発者はドメインエキスパートの頭の中にあるものを引き出していく
          • イテレーティブな開発
          • 開発者とドメインエキスパートの密接な関係性

DDDのメリット

  • ドメインエキスパートと開発者を同じ土俵に乗せることで、プログラマーの視点だけでなく業務側の視点も入れられる
  • ソフトウェアを理解している人を一部だけという状況をなくせる
  • ドメインエキスパートとソフトウェア開発者、そしてソフトウェアそのものとの一切の通訳が不要になる
  • 設計がコードであり、コードが設計になる
    • 知識の継承、ビジネス要件に伴う機能変更にすばやく対応できる

DDDの要素

  • 戦略的設計と戦術的設計に分類される
    • 戦略的設計 -> 概念的な要素
      • ユビキタス言語
      • 境界づけられたコンテキスト
      • コンテキストマップ
    • 戦術的設計 -> 技術的な要素
  • 戦術的設計だけでもDDDの恩恵は受けられるが両者が組み合わさったときのような大きな利益は生まれない

ユビキタス言語

  • ユビキタス言語とは、ドメインエキスパートやソフトウェア開発者を含めたチーム全体で作り上げる共通言語のこと
    • 誰かが規定するものではなく、チーム内で議論し合意の上で最善の用語を見つけていく
    • ユビキタス言語は、チーム内での会話・ドキュメント・ソースコード全てに適用を徹底すべきもの
  • ユビキタス言語の見つけ方
    • 現在のドキュメントを調べ、ユビキタス言語の候補になりそうなもの、問題がありそうなものをピックアップする
      • 次の場合には要注意
        • 同じものを表す用語が複数ある
        • 概念はあるのに名前がない
        • ビジュアルはあるのに名前はない
    • ドメインエキスパートの話す用語を観察し、用語やフレーズをピックアップする
    • ピックアップした用語やフレーズをチームで議論してユビキタス言語として確立する
    • 名前のない概念、曖昧な概念をはっきりさせ、名前をつけてユビキタス言語として確立する
  • ユビキタス言語
  • 一度決めたらそれっきりではなく、ユビキタス言語も育っていく

ドメインモデル

  • ドメインを反映したモデル
    • 名前・関係性・振る舞いなどが表現されていて、チームメンバー全員が同じものを思い浮かべるもの
  • DDDでは設計がコードであり、コードが設計である
    • ドメインモデルはドキュメントに残されるものではなく、コードで表現されたドメインモデルが最も長期間ユビキタス言語とドメインの現状を正確に表現し続ける
    • ドメインモデルをコードに落とし込む段階で、考慮漏れやより良いモデル、ユビキタス言語を見つけることがある。この場合には、ドメインモデルやユビキタス言語にフィードバックし、常にコードが正確にドメインモデルを表現するようにする
  • ドメイン、ドメインモデル、ソフトウェアモデル、オブジェクトモデルの関係性
  • ドメインモデル貧血症
    • ドメインモデル(と呼んでいるもの)が下記のような状態にあることを指す
      • getter/setterのようなものしかない、ただの値を保持するだけのオブジェクトである
      • モデルを利用する側がほとんどのロジックを抱えている
    • ドメインモデル貧血症となっているコードにはほとんど意図が反映されていない

ドメインとは

境界づけられたコンテキスト

  • ドメインモデルがどこに属するかを表すもの
  • 新規のプロジェクトなどは1つのサブドメインに対して1つの境界づけられたコンテキストになるが、そうではないケースもある
    • 対象としている領域は同じサブドメインだが、クライアント側とサーバー側に別れている場合などはチームの境界が(ユビキタス)言語の境界にもなっていることが多くこの場合は異なる境界づけられたコンテキスト
  • 境界づけられたコンテキストのサイズを間違える原因として多いもの
    • 言語的な境界ではなく技術的な境界を考えてしまっている
    • チームの開発要員へのタスクの割当を考慮してしまっている

コンテキストマップ

  • 境界づけられたコンテキスト間の関係性を描いたもの
  • 注意点
    • 関係を省いたり単純化したりせず現状を表現する
    • 境界づけられたコンテキスト自体もユビキタス言語にすること
  • 境界つけられたコンテキスト間には下記のような関係がありうる
    • 共有カーネル
    • 顧客/共有者の開発チーム
      • 2つのチームに顧客と供給者の関係を確立する
    • 順応者
      • 相手のコンテキストに従う
    • 腐敗防止層
      • 隔離するためのレイヤを作成する
    • 別々の道
      • 2つのコンテキストのつながりを持たない
    • 公開ホストサービス
    • 公表された言語
    • 巨大な泥団子

感想

  • DDDについて今まで実装の話を少し読んでみたりしてピンとこなかったのがとても身近になったしDDDを本格的に学ぶモチベーションが上がった!
  • 前の職場では、エンジニアと非エンジニアが違う言葉使っているというのはあったな、と思った。それが原因で意思疎通に支障が生じることもあったと記憶している。ユビキタス言語を育てる、ということを取り入れるだけでもいいコミュニケーションにつながりそう
  • まだ先は長そうなので頑張ろうと思う
    • 次は下記資料の1番上のドメイン駆動設計の要約を読む

他のドメイン駆動設計のよさげな資料