DDD (Domain Driven Design) はいわずとしれた業務アプリケーション開発の「思想」です。一方で Wagby にも思想があります。ここではDDDの観点からWagbyを見ることで、Wagbyの思想の特徴を明らかにしてみます。
DDD の思想
私の理解では、DDDとは「業務知識をモデルに埋め込む」ことが核です。
業務の複雑さをドメインモデルの構造として表現します。具体的にはEntity, Value Object, Aggregate, Domain Service などを組み合わせます。そのため扱う業務が複雑になるほど、オブジェクト間の関係も複雑になりやすいです。
Wagby の思想
Wagbyの思想を一言でいうと「業務知識を標準化された構造へ配置する」ことです。
業務の複雑さをクラス構造だけで表現しない、という立場です。データ構造は明示的に定義し、処理は役割別クラスへ分離します。さらに処理の実行順序をフレームワーク側で規定します。具体的にはInputFilter → Validator → Calculator → Repository →…という順序を規定します。
DDDからみると、アンチパターンである「貧血ドメインモデル + 巨大Service」にみえるかもしれません。これは誤解で、実際にはデータと処理を分離し、処理を役割別コンポーネントとして標準化しています。
技術者からみた「知識」の扱い
ここまでの両者の思想の違いがどこに現れるか、をみていきます。まず「知識」について。
DDDは「業務知識 x DDD知識 x プロジェクト固有設計」から成り立ちます。設計ノウハウのかなりの部分がプロジェクト固有になります。
一方Wagbyは「業務知識 x Wagby共通規約」から成り立ちます。プロジェクト固有の設計知識を減らし、Wagbyという共通知識へ置き換えるようにします。
この差は、Wagby技術者は別プロジェクトでも活躍しやすいという違いにつながります。Wagbyの規約を知っていれば、おおまなか流れはもうわかっているので、あとは業務知識をインプットすることでプロジェクトに参加できます。この点は、多くのWagby技術者が実感していると思います。
RDBの扱い
これは私の主観ですが、DDD的な設計では、オブジェクトモデルを中心に考えることと、正規化されたリレーショナルモデルを中心に考えることは、異なる最適化軸があると思っています。例えばAggregate境界とテーブル境界は一致するとは限りません。このとき、主となるのがオブジェクトモデルのため、永続化モデルとのマッピングが別の設計課題となる場合があります。
一方Wagbyは、RDBを単なるストレージではなく、業務データを長期間維持するための重要な資産であると位置付けています。そのため設計の初期段階から、業務データ構造とRDB構造を対応させます。あとづけにはしません。別の見方をすると、RDBは最初から設計の大きなウェイトを占めます。
制約の中の自由
一般的な開発現場では、自由が尊ばれます。これは同じ要求を10人が10通りで実装できることにつながります。DDDもこれに準じていると思います。
ところがWagbyは、「Whereを制約し、Whatを自由にする」というポリシーです。「どこに書くか」「いつ呼ばれるか」「どう接続するか」はWagbyが決めています。一方で「どんな業務ロジックを書くか」は開発者に任せます。実装方法の自由を減らすことで、業務ロジックを書く自由を確保するというものです。この結果、誰が実装しても、似たようなコードになります。
障害の切り分け
先に述べたように、DDDは開発の自由度が高いのが魅力です。そのため、障害切り分けでは、この処理はどこで実行されているか？を探すところからデバッグが始まります。
Wagbyは処理順序が決まっているため、確認ポイントを順番に追えます。入力→変換→検証→業務計算→永続化という手順が定まっているためです。つまり、Wagby技術者はコードを読む前から、どこを調べればよいかというアタリをつけられます。単なるObservabilityにとどまらず、Predictability(予測可能性)を設計によって高めるという考え方です。
AI時代のコード生成
ここまでを踏まえ、もっともホットなAIによるコード生成を考えます。
DDDでは、同じ要求を与えてもAIはこれを「Entityに実装する」「Domain Serviceに実装する」「Application Serviceに実装する」「Specificationを作る」「新しいValue Objectを導入する」など、さまざまな設計を生成できてしまいます。多様性があることをメリットとするか、制御しづらいとするかはプロジェクトチームの考え方によります。
しかしWagbyは最初からAIに与える探索空間を大幅に小さくできます。「入力補正はInputFilter」「検証はValidator」「計算はCalculator」と決めているためです。AIモデルを制御するAIハーネスという観点でみると、Wagbyの制約は、人間のためだけではなくAIにとっても有効になります。
まとめ
ここまでの文章を一覧表で整理しました。
| 観点 | DDD | Wagby |
| 基本思想 | 業務をドメインモデルとして表現 | 業務を規約化された構造へ配置 |
| データと処理 | オブジェクトとして統合 | 意図をもって分離 |
| ロジック配置 | ドメインに応じて設計 | 役割別クラスへ配置 |
| 処理フロー | モデル設計に依存 | フレームワークが規定 |
| 設計自由度 | 高い | 意図をもって制限 |
| 必要な設計知識 | 業務 + DDD + プロジェクト設計 | 業務＋Wagby規約 |
| RDB | ドメインモデルとは別の関心事になり得る | データモデルとして早期から重視 |
| プロジェクトへの途中参加 | プロジェクト固有設計の理解が必要 | Wagby経験を横展開しやすい |
| 障害解析 | 設計を理解して追跡 | 調査箇所・順序を予測しやすい |
| AIによるコード生成を使う | 設計選択肢が多い | 探索空間を制約できる |
WagbyはDDDとは違う視点から、独自のメリットを追求していることをお伝えしました。この発想は今のAIコード生成時代にマッチしているのではないか、と考えています。
