要約
DDD（ドメイン駆動設計）の難しい概念に苦労していた私が、実は「業務フロー」と「帳票」を分析する中で、DDDの核となる「モデル」や「集約」と共通する概念を学んでいたというお話です。
気づき
DDDを学び直そうと、バイブルであるエリック・エヴァンスの『ドメイン駆動設計（DDD）』を再び手に取りました。
かつては難解だった抽象的な概念が、驚くほどスムーズに理解できるようになり大興奮しています。
その興奮とともに、自身の過去の経験を振り返り、ある重要な事実に気づきました。
私が以前書いた記事では、「しなやかな設計をどう維持するか」という実装側の話が前面にでています。しかし、その設計の根幹をなす「モデル」や「集約」といった構成要素を、どうやって見つけ出したのかについてはあまり触れていません。
これは私がDDDの概念を理解していなかったからだ、と考えていましたが、実は別の道から同じ哲学にたどり着いていたのではないかと気づいたのです。
『業務フロー』と『帳票』が教えてくれたこと
システム開発手法で、私が最初に触れたのはER図によるデータ管理手法でした。
しかしそれだけでは「現場の要望を、どのように実装へ落とし込むか」については答えを得られなかったのです。
その状況を打開する方法を得たのは、渡辺幸三氏の『業務システムのための上流工程入門』です。
この書籍は、業務システム開発の上流工程を具体的・実践的に解説しています。
特に、現場の「帳票」や「台帳」を分析することから始め、業務フロー、データ、機能の三要素を整理するという実践的なアプローチが特徴です。
この手法を通して、私は以下のプロセスを学びました。
- 業務担当者と会話を重ね、業務の「流れ」と「開始イベント」を把握する
- 業務に必要な帳票・画面から、詳細なデータモデルを構築する
- 構築したデータモデルを元に、機能や画面に落とし込む
- データモデルや機能について、業務担当者とレビューを繰り返す
このプロセスは、「どのようなデータがひとまとまりで扱われるか」を整理します。さらに、業務が複雑になると、システムをシンプルに分割することも示されていました。
これは、DDDでいう「モデル」や「集約」を発見する作業につながっています。
DDDの哲学は、身近なところにあった
DDDと渡辺氏の手法には「業務を深く理解し、それを共通のモデルとして表現する」という点で非常に近しい考え方を持っています。
そのため、今回の私の体験は、
- 渡辺さんの手法で現場の業務モデルを緻密に洗い出した後
- DDDの考え方を用いて、そのモデルに沿ったドメインロジックを設計していく
といった相互に補完するようなアプローチだと考えられます。
もしあなたがDDDで「どうやって設計の要素を見つけたらいいのか」と悩んだら、実際の業務で使われている書類や、仕事の流れをじっくり見てみてください。そこに、答えが見つかるはずです。