ドメイン駆動設計

これまで名前は知っていましたが、取り組んでいなかったDDD（ドメイン駆動設計）ですが、今回のプロジェクトでは、このDDDを採用しています。というのも、これまでは自社サービスの開発が多く、ドメイン＝開発チームということもあり、あまり重要性を感じていなかったたためです。それが、今回のプロジェクトは自社グループのインハウスの開発部門として、サービスを提供している事業部とともに開発を行うこととなり、ドメイン＝事業部との対話が必要となりました。

さて、まずはDDDの勉強からということで、すでにDDDを実践の方ならご存知の本であろう「エリック・エヴァンスのドメイン駆動設計」を購入しました。500ページを超える内容に戸惑いを覚えつつ読み進めていきます。より実装に近い、「ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本」を購入したエンジニアもいたので併せて紹介しておきます。

第1部はドメインの知識を抽出してドメインモデルを作るまでの内容で、プロジェクトの成否を分ける最も重要な部分との印象です。そもそも、この本の英語でのサブタイトルが "Tackling Complexity in the Heart of Software" と、強い単語 "Tackling", "Heart" が使われていることなどからも第1部がとても重要なことが分かります。

そこで、今プロジェクトでは、開発チームにドメイン担当をつけ、ドメイン側からも開発担当を数名選び、混成の開発チームをつくりました。毎週の定例打合せを設け、ユビキタス言語として、ドメイン側の用語とその意味をまとめたドキュメントの作成や、業務フローを整理したシーケンス図やユースケース図などの作成を行いました。これらのドキュメントを基にドメインモデル図、クラス図と実装に向けてのドキュメントを整理していきました。

このクラス図、これまでの開発方法で作ったものと異なり（そもそもちゃんとしたクラス図自体つくっていませんでしたが）、かなり要素が多く、現実のサービスをリッチに表現できていることがわかりました。そりゃドメイン知識もりもりで作成したので当然ですが、改めて見ると実際のサービスの複雑さが分かります。当初考えていなかった副産物として、クラス図を作る過程で、業務の方を改善したほうが良い点が見つかることもあったので双方にメリットがありました。

今回はひとまずここまでとし、いずれ実装の方のストーリーも追加したいと思います。なかなか敬遠しがちなDDDですが、やってみると時間はかかりますが、双方の理解がかなり深くなったため、今後の開発でこれが有利に働いてくると思っています。長期的な開発を行うときにはおすすめですね。