はじめに
私は現在、基幹システム移行プロジェクトをすすめています。
そこでTDD/DDDの開発体験を得て、効果を実感しました。
さらなるヒントを得ようと、積んだままだったドメイン駆動設計の書籍を改めて読み返しました。
読んだのは、『ドメイン駆動設計をはじめよう』、エヴァンス本、ヴァーノン本、です。（参考書籍はこちら）
今後の開発に役立つと感じた考え方を７つ整理します。
1. どこに適用すべきかを見極める「戦略的DDD」
私は再読にあたって「開発現場のあらゆる場面でDDD手法を活用すれば幸せになれる」と期待しながら読み進めました。しかしそれは「銀の弾丸1」を求める行為でした。
戦略的DDDで判断し、戦術的DDDをメリハリをつけて実施することが有用です。
例えばシンプルCRUDのような場面では、複雑度があがるだけのオーバースペックになる可能性があります。
判断基準は、事業にとっての重要度が指標になります。
ビジネスの差別化に直結するコアドメインであれば、投資したコストの回収も容易になります。
「ビジネスケイパビリティ（事業能力）」という視点から、コアドメイン、汎用サブドメイン、支援サブドメインといった分類を行うことが、戦略的DDDの第一歩です。
2. 「境界付けられたコンテキスト」と「ユビキタス言語」の関係性
境界付けられたコンテキスト（Bounded Context） の概念が難しかったです。まるで雲とつかむような感覚でした。
なぜこれが重要なのか？
それはユビキタス言語の「境界」を定めることです。
たとえば、「商品」という言葉一つとっても、ECサイトの在庫管理部門とマーケティング部門では、その意味合いや関心事が異なります。同じ言葉でも文脈を区切らなければ無限に遠くまで意味が広がりかねません。有界であるべきです。
コンテキストごとに扱う関心事を明確にし、それぞれに合わせたドメインモデルを構築することで、可読性と保守性が向上します。
先ほどの例でいうと
- 「商品マスタ」のデータ構造が、在庫やマーケティングの関連項目をすべて保持している
- そのデータ構造で複雑な業務ロジックを記述している
このような構造は「巨大な泥団子（Big Ball of Mud）」のにおいです。
3. テーブル構造に縛られない「戦術的DDD」
以前の私は、モデリングで発見したデータ構造をDBのテーブル構造とし、コードも同じ構造を維持することを重視していました。
しかしこれは、テーブル構造に依存したシステムでした。変更が発生するとシステム全体に影響が波及する設計です。
戦術的DDDの様々な手法は、この変更の波及を防ぐことに役立ちます。
DBの物理的なテーブル構造に縛られるのではなく、メモリ上の「ドメインモデル」（データとロジックをカプセル化したオブジェクト）に注力することが重要です。
余談
テーブル構造の末尾に追加すればエラーは起きませんが、可読性・保守性が下がっていきます。
この可読性・保守性を重視する姿勢は以下の体験が根源となっています。
COBOL時代の処理を見る機会が多いのですが、当時は処理にif文を追加することが「安く早く安全」に機能を追加できると考えられていた節があります。
結果、現在の私は処理の全体像を読み解くのが難しくなってします。
40年前のシステムですので、当時の状況や計算リソースを考えれば妥当な判断なですが、現代に持ち越すのは考え物です。
4. マイクロサービスは「目的」ではない
「ドメイン駆動設計を始めよう」に記載されている内容です。
マイクロサービスは魅力的なアーキテクチャですが、安易に導入すると「分散した大きな泥団子」になりかねません。
分散システムであるマイクロサービスの適用は、適切な設計がなければ、かえって複雑性が増大します。
ビジネス上の必要性と技術的な成熟度を考慮した上で慎重に判断すべき手段です。
5. 技術ではなく「業務そのもの」を深く理解する
書籍を再読し、私が以前から愛用していたユースケースシナリオや渡辺幸三氏の手法と、戦略的DDDと本質的な目的が似ていると気づきました。
これらはアプローチこそ違えど、「技術ではなく業務そのものを深く理解する」ことを目的としています。結果的に、これらの手法は「業務のスコープ整理」という戦略的DDDにも通じる考え方を私に与えてくれていました。
6. 「エンジニアリングモデル」と「コントラクトモデル」
ヴァーノン氏の書籍に登場2した「エンジニアリングモデル」と「コントラクトモデル」という対比は、ソフトウェア開発におけるアプローチの根本的な違いを明確に示しています。
-
コントラクトモデル: 建築業のように、「何世紀にもわたる研究で確立された予測可能な物理法則」に基づいて標準化された手法で設計し、正しく作業することが確実性につながる考え方。ソフトウエア開発の文脈では、ウォータフォール開発のイメージでしょうか（一般化されすぎですが）。設計により作業が正確に指示され、失敗は許されない環境を作ることが効率化につながるという考え方
-
エンジニアリングモデル: 不確実性が高い分野で有効な手法です。SpaceXの例3にあるように、実験とフィードバックを繰り返し、不確実性に対処する「探索」的なアプローチです。不確実性が高い場面では、先ほどのコントラクトモデルよりも早く低コストで対処できる可能性があります
なぜソフトウェア開発においてアジャイルな手法が重視されるのか、その本質が見えてきます。
7. AIを活用して「ビジネス視点」で設計をチェックする
前回の記事で紹介したように、私は複雑な業務ロジックをTDD/DDDの手法で実装しました。
AIで、この実装の簡単な設計書や構造図を生成し「ビジネス視点」でレビューしました。
そうするとビジネスの言葉で読む設計書や構造図には違和感がありました。
つまり「技術寄り」に偏っている部分を特定できたのです。
これは設計の意図がビジネスと乖離していないかを確認する有効なフィードバックループです。
まとめ
記憶が新しいうちに、再読で得た気づきを整理しました。
開発経験を得る前は難解だった書籍ですが、今ではまったく違った世界に見えてくるのは非常に楽しい体験でした。
「言われた通り作るシステム」ではなく、「システム構築後もフィードバックを繰り返して探索的な開発体験を得られる」ような環境が欲しいですね。この目標にTDD/DDDの手法は有用だと感じています。
これらの気づきを、今後の基幹システム移行プロジェクトに役立てていきます。
参考書籍
- ドメイン駆動設計をはじめよう
- エリック・エヴァンスのドメイン駆動設計
- 実践ドメイン駆動設計
- 要件最適アーキテクチャ戦略