MENU

『ドメイン駆動設計』第17章 エヴァンス本 まとめ&読破した感想

DDD

前回のふりかえり

第16章 大規模な構造

  • 境界づけられたコンテキストや蒸留などの方法ではシステム全体の構成は表現できないので、開発者が全体像を見えるようにする必要がある。(大規模な構造)
  • 進化する秩序(大規模な構造の基本思想)
    • 大規模な構造を一度に設計するのは不可能なので、アプリケーションと共に進化させる必要がある。
    • 場合によっては途中で全然違う構造になる。
  • 大規模な構造のパターン
    • システムのメタファ
      • メタファを使うことで、チームメンバーのシステムへの理解を促すことに役立つのなら、それを大規模な構造として採用する
    • 責務の階層
      • 巨大なモデルに一貫性を与えるのに、レイヤ化した責務を当てはめる
    • 知識レベル
      • ソフトウェアを二つの側面に分け、知識レベルでモデルの構造とふるまいを記述することで、制約を明示的にすることができる
  • DDDの最終形態
  • 着脱可能コンポーネントのフレームワーク

第17章 戦略をまとめ上げる

第4部で登場した境界づけられたコンテキスト・蒸留・大規模な構造を組み合わせる

大規模な構造と境界づけられたコンテキストを組み合わせる

  • それぞれのコンテキストが、統合されたシステム全体でどのような役割を果たし、どう関係しあっているかは、大規模な構造を使って、コンテキストマップを構成することでわかるようになる
  • コンテキストと大規模な構造は、様々な適用パターンがある。
    • 単一のコンテキスト内に大規模な構造を取り入れる。
      • 単一の境界づけられたコンテキスト内で維持できる複雑さの限界が押し上げられる
    • コンテキスト自体を大規模な構造の要素にする
      • コンテキスト間の関係を表現することができる
    • レガシーシステムを大規模な構造で表現する
    • コンテキストをまたがって大規模な構造が存在する

戦略的設計上の意思決定を行うために必要な6つ

  • 意思決定はチーム全体に伝えなければならない
    • 誰もが戦略を理解して、それに従うのでなければ意味がない
    • よって、中央集権型のアーキテクチャチームを中心にチームが構成されることになる
  • 意思決定プロセスはフィードバックを吸収しなければならない
    • 大規模な構造を作成したり、それらを蒸留するにはドメインに対する深い理解が求められる
    • そこまで深い知識を唯一持っているのはアプリケーションチーム
    • フィードバックループにはアプリ開発チームの参加が必要
  • 計画は進化を許容しなければならない
    • 意思決定を不変のしてしまうと、チームは変化に対応できない
    • 継続的な変更を重視することで、洞察の深まりに応じて大規模な構造が作られる(進化する秩序)
  • アーキテクチャチームが、最も優秀な人材をすべて吸い上げてはならない
    • すべてのアプリ開発チームに強力な設計者を入れることが不可欠
  • 戦略的設計には、ミニマリズムと謙虚さが必要である
    • アーキテクトが意気込んで、必要以上にシステムを作りこみすぎるとそれがアプリチームの妨げになることがある
    • 本当に必要なものだけを含むようにコアモデルを設計しないといけない
  • オブジェクトはスペシャリストだが、開発者はジェネラリストである
    • しなやかな設計は、実際にコードを書く人が作業しないと生み出せない

読破しての感想

結構かかってしまったが、エヴァンス本を読破した。

  • 「DDDという手法を開発に取り入れると、保守運用しやすいシステムを作れるらしい」くらいの知識量から入ったけれども、なんとか最後まで読めました。
  • 最初の頃の自分は「DDDって何？値オブジェクトとかエンティティは聞いたことある」くらいなレベルだったので、やっぱり一回読んだくらいじゃ全体像を把握することはできませんでした。
  • 個々の章だけで見るとある程度理解できたと思いますが、じゃあ「それを踏まえてDDDやろう！」となっても、現状だとかなり厳しいです。

ただ、得られたものはたくさんあったように思います。


[得られたものたち]

  • 長期間の保守・運用に耐えることができるアプリケーションの姿が(ある程度)理解できた
    • 今までは業務ロジックが画面側に存在したり、複数箇所にコーディングされてるということすら、問題だと思えていなかった
    • ぼんやりとでも「よりよいアプリケーションの姿」の像を持てたことで、日々のコーディングがやりやすくなった
  • 適切に作られたドメインモデルが無いと、いくらアーキテクチャや実装方法を検討しても良いシステムにはならないということがわかった
    • そもそも自分にはモデリングのスキルが一切なくて、DDDとか言う前にモデリング・設計の技法を学ばなければならないなと思えた

読む前は「なんかよくわからないけどDDDを理解できたら良いシステムが作れそう」くらいの段階でしたが、今は「自分にまず足りてないのはドメインモデリングの経験」といった感じで、より具体的に課題を設定することができるようになりました。

結局エヴァンス本とは？

実際に読破した上で、エヴァンス本とDDDを二行でまとめると

こんな感じかなと思いました。 当初の私はDDDを何かの魔法くらいにしか捉えられて無かったので、自分にとってはこれが分かっただけでもそれなりの収穫です(-_-;)


最後に

数日前に『ユースケース駆動開発実践ガイド』を読み始めていて、しばらくはこの本でドメインモデリング～実装までの流れをしっかり学ぼうと思います。

ユースケース駆動開発実践ガイド | ダグ・ローゼンバーグ, マット・ステファン, 三河淳一, 佐藤竜一, 船木健児 | コンピュータ・IT | Kindleストア | Amazon

しばらくして自分がもうちょっと成長できたら、またエヴァンス本に帰ってこようかなと思いました。 目を通して頂いた方々、ありがとうございました。

参考