ドメイン駆動設計を成功させるためのICONIXプロセスを考える

戦略設計と戦術設計

林宏勝氏：今回「DDD時代に考えたいICONIXプロセス」というタイトルで発表します、林です。

今日話すことは、Today's Topic ICONIX in the DDD era。DDDのモデリングをするにあたってICONIXをどう生かしていくか「DDDをやりたいけど、ICONIXは何に使うの？」みたいな話ができたらと思います。時間の都合上、ICONIXの詳細なやり方は、たぶん説明する時間はないと思うので、ご了承ください。

DDDに興味があることが前提でこの話をスタートしますが、「DDDって何だっけ？」というのを最初に振り返っておきたいなと思います。

DDDとは、端的に言うとドメインの運用者と開発者がコミュニケーションをとりながら「モデル」を育てる。そして、そのモデルをソフトウェアとしてコードで表現するための設計手法かなと思っています。いわゆるMMD（モデル駆動開発）ですね。

その中でもDDDは、戦略設計と戦術設計と呼ばれる2つのものに分けることができます。戦略設計を一般的な表現で言うと、ドメインエキスパートとともに、ユビキタス言語を使いながらモデルを育てるための設計手法。コンテキストマップなどが定義されています。

戦術設計というのは、作ったデータやドメインモデルをいかにコードに落とし込むかという実装パターンやテクニックです。

一般的には、だいたいオブジェクト指向のテクニックを使って、そのモデルをそのままコードで表現する。モデルとモデル以外の部分。アプリケーションを支える部分とアプリケーションのコアとなる部分をうまく分離する。そのかたちの実装パターンやテクニックをTipsで表しているのが、戦術設計になるのかなと思っています。

みなさんドメイン駆動設計、DDDを実践されたことがある方、戦略設計が難しいと思われませんか？

「戦略設計で結局何をすればいいかわからない」みたいな意見を声を聞くことが多いです。この部分にフォーカスしたいと思っています。

今回の勉強会は、設計とかオブジェクト指向とか、そういうのがテーマなだけあって、V字モデルや一般的なシステム開発に流れや要件定義といった話がありました。

もっとビジネスな話でいうと、RFPとかそういうのも出てくるかもしれないんですけど、開発側が気になり出すのは、この要件定義ぐらいからです。基本設計と詳細設計をして、実装して、ユニットテスト、ITaやITbからSTを挟んでUAT、最後に受け入れテストをする。そこから運用と稼働が始まるのが一般的な流れだと思いますが、そもそもDDDで言うところの戦略設計は、どこからどこを指しているのかわかりづらいのかなと。

ドメインエキスパートと話して、いろいろ作ろうと言っている時点で、なんか要件定義しているようなところもあります。基本設計、いわゆるアーキテクチャのことなどを考える部分がメインになっているので、やっぱり基本設計にあたるのかな？　と思ったり。この辺がフワッとしていて、だから戦略設計は、結局いつ・だれが・何を・どのタイミングでやるというのが少しわかりづらいのかなと思っています。

2019年ぐらいから、DDDはけっこうバズワードになっています。増田さんだったら「もう何年も前から流行っているよ」とか言うかもしれないですが。自分の観測範囲だと2019年ぐらいから突然盛り上がりを見せて、すごい話題が多いかなと思っています。この辺の戦略設計についてあまり話題に上がってこないので、今回フォーカスをして、その中のプロセス例を紹介しようかなという流れです。

ICONIXプロセスとは

遅くなりましたが、自己紹介から。株式会社ミライトデザインのCEOと、Jocyという美容室のサブスクリプションサービスを運用している会社のCTOをやっています。Twitterアカウントは@hirodragon112です。2020年の2月にObject-Oriented Conferenceというカンファレンスの主催もやらせてもらいました。

本題のICONIXプロセスについて。とりあえずICONIXプロセスってみなさんご存じですかね？　20年ぐらい前に発売された『ユースケース駆動開発実践ガイド』という、ちょっと有名なピンク色の本があるのですが、そこで、ざっくり言うとユースケースからソースコードを作ろうというプロセス、ICONIXプロセスを紹介している本です。

そもそもユースケースって何？　というところから。ユースケースを作るときにどういう視点で作るのか。UMLとかを書いたことがある方とかは、当然ご存じだと思います。ユースケースは基本的に、システムが何をできるかを表現したモデルです。

なので、ユースケースを分析するという作業で、どう使われるべきシステムなのかという工程があると思います。そのとき分析者は、今紹介した本の序章からそのまま持ってきますが、分析者は抽象的で、かつ本質的な技術に依存せず、実装から独立したユースケースを書く。まさにその通りだと思います。

アクター目線でユースケースは書かれるので、このシステムで何ができるのか、帳票を登録できるのか、あるいはログインできるのか、といったユーザー目線で何ができるというのを表したのがユースケースです。

裏でどういう技術や言語を使用しているかは、一切気にしない。Zoomがどんな技術で利用されているかはわからないけど、オンラインで会話や画面の共有できる。みたいなことが、ユースケースになるのかなと思っています。

次は開発者目線でユースケースがどう見えるのか。先ほど前提で出てきていますが、「不明瞭で曖昧、不完全で正しくない」。システムでやりたいことはわかるけど、それをどう作ればいいか、ユースケースには一切表現されていない。抽象的で具体的な方法論が記されていないのが、ユースケースになるのかなと思います。

ICONIXプロセスとは、そのギャップを埋めるためのプロセスなのかなと考えています。本質的ではあるけど、不明瞭なユースケースを具体的な実装に変換するためのフレームワークという位置付けです。

これも今の本に書いてあって、その本でも引用で別の方の言葉として載っているんですけど。論理的に「理論」と「実際に」に違いはないけれども、しかし実際には違いがあると。これがまさにシステム開発なのかなと思っています。

ICONIXの6つの工程

ICONIXはどういうプロセスなのか？　6つの工程の紹介から。まず要求、分析／予備レビュー、予備設計レビューがあって詳細設計、詳細設計レビュー、実装。つまり見てもらうとわかるんですけど、要求から実装まで、一気通貫ですべてプロセシングされているというか、カバーしているプロセスです。

それをさらに具体的に分割すると、要求の中には機能要求、ドメインモデリング、振る舞い要求があります。この振る舞い要求というのが、いわゆるユースケースにあたる部分と要求のレビュー。2番目の工程である分析には、ロバストネス分析があるんですけど、このロバストネス分析以降がICONIXのカギです。ICONIX＝ロバストネス分析というぐらい肝になります。

それとドメインモデルの更新。論理的な名付けとか、ドラフト版ユースケースをもっとブラッシュアップするみたいな工程です。その予備設計をレビューした上で、詳細設計に入って、シーケンス、ドメインモデル、静的モデルを整理して、詳細設計をレビューしたら、あとは実装に入ります。そこからコーディングと単体テスト、結合、シナリオ、というかたちで進んでいくのが、ICONIXプロセス全体での話です。

さっきのシステム開発の頭からお尻までの工程の中の要件定義、UAT以外の部分をカバーしているのが、ICONIXだと思います。今日の話の内容が「ICONIXプロセスをただやりましょう」というよりは、タイトルの「DDD時代に考えたいICONIXプロセス」。

DDD時代のICONIXプロセス、つまりDDDとそのICONIXをどう融合していくべきなのか？ 自分も正解はわからないんですが、実際に自分が設計をやるときに、DDDとICONIXのどちらも使っていて、「こんな感じでやっているよ」という紹介です。

その前にDDDの戦術設計と戦略設計について話します。先ほどちょっと話しましたけど、もう少し突っ込んだ捉え方をすると、戦術的DDDというのが理解しやすいです。戦術的な、しかもオブジェクト指向のパターンなので、開発者はわかりやすい。なぜなら開発者がプログラミングできるのは当たり前なので、プログラミングに近ければ近いほど理解しやすいからです。

また、各パターンというのは、今の時代Googleでも何でも調べれば答えがすぐに見つかります。「集約どれ？」「Aggregateはこうだよ」「Entityはこうだよ」「ValueObjectはこうだよ」と言った疑問も簡単にわかります。それこそ、増田さんの本とかを見てもらえれば、だいたいのことが載っているので、答えが見つけやすいのではないでしょうか。

それに比べて戦略設計は、難しく感じている場合が多いのかなと思います。それは実装とかツールとかパターンの話とかと違って、戦略設計は実際のプロダクトの中にのみ答えがある。それぞれ要求が違うので、ググったところで答えが出てこない。「あなたのシステムはこうだから、今からこうしたほうがいいですよ」みたいな話があるので、調べても正解がわからないから、けっこう難しく感じる。

だから例えば「ドメインエキスパートとともにユビキタス言語を使いながらモデルを育てましょう」と言っている戦略設計部分の「モデルを育てるってそもそも何？」とか「ドメインモデリングは具体的にどうやるの？」とか。「ドメインエキスパートと話すことができれば、モデルが作れる」とか、全然イメージが沸かないんですよね。

なのでDDD時代のICONIXをちょっと……。この要件定義から戦略設計に入る間に分析設計があることが重要。要件定義から分析設計をとばして、戦略設計をするのは困難だと思う、ということが今日伝えたいことです。

このICONIXプロセスの中でも6工程ありましたけど、この1、2、3工程はICONIXの分析部分を取り入れていけば、より効率的に戦略面のDDDをまわせるようになると思います。

ドメインモデリングとユースケースモデリング

ICONIXの詳細について話す時間がないので、詳しくは『ユースケース駆動開発実践ガイド』を読んでください。

基本だけ簡単に紹介します。まず要求のプロセスの中で最初にあるのが、スタート地点のドメインモデリングです。ここで注意したいのが、ドメインモデルという単語は。いろいろなところ...DDD本やエヴァンス本、PofEAA本から先ほど紹介した『ユースケース駆動開発実践ガイド』などに出てきます。しかし、けっこう粒度が違うので、ここでいうドメインモデリングは、いわゆる実装に向けたクラス図とかドメインモデル図と思わないほうがいいです。

プロジェクトの用語集を一番先に作ることが重要。自分で思う「ドメインモデルって何？」「ドメインモデリングって何？」と。基本はこれをベースにしています。これは単なる用語なので、そのプロジェクト内に出てくる言葉をすべて洗い出そうという試みです。完璧でなくてよくて、あとから見つかったら、用語を追加すればいいと思っています。

その中で大事なのは、システム目線の作業ではありません。現実世界に焦点を置きながら、現実世界での活動とか概念に対してすべての名前を付けていくというのが、ドメインモデリングです。ユースケースを洗い出す前に、必ず行なう作業になっています。

その次がユースケースモデリング、振る舞い要求です。機能要求はRDRAとかを使っていると、要件定義の前半である程度出てきます。その機能要求は機能に対する要求です。それをユースケースモデリングすることで、振る舞い要求に変えていきます。

このユースケースモデリングで重要な点は、ユースケースとドメインオブジェクトに割り当てる作業です。なので、このユースケースモデリングはユースケース図とユースケース記述、これが2つで1セット。ユースケース図だけを書いたらもったいないので、記述も必ず書きましょう。

このときに通常ケースと代替ケース、通常コースとか代替コースとか言いますけど、それを考慮しながら作業して、関連に時間をかけない。これはincludeなのかextendsやinvokesなのかと疑問がでます。これはすごい些細なことで重要ではないので、何が起きているのかだけ着目して、ユースケースを洗い出していきましょう。

ユースケースモデリングが終わったら、要求レビューです。先ほどのドラフトのユースケースができたタイミングで、まずは顧客に1回「今回作るシステムってこういうユースケース、こういう使い方をされる想定ですよ」と伝えます。要件定義のお尻の部分と混ざる部分があると思いますが、ここで1回レビューを挟むことで、今から進むシステム開発の不一致を防げます。

そのときにドメインモデルで一番最初に作ったシステムを意識しない、用語集のみでユースケースができます。これはDDD的に言うと、いわゆるユビキタス言語ですが、その言葉で作成されているかどうかも確認します。作成されていれば、顧客にはわかります。ユースケースからすべての要求が追跡できるか。これもRDRAの考え方ですけど、すべてのWhyをつなげたいというのが、RDRAレイヤーです。

その実装のWhyをたどっていきます。最終的には要求があるというのをつなげ、関連付けるのがRDRAです。それと同じような目的として、ユーザーの望みがユースケースに網羅されているか。ここもユースケースモデリングから外れた機能は、今から作るシステムでは生まれないので、ここで漏れていると、望み通りのシステムにはなりません。

それをロバストネス分析にかけますが、これは分析でもあり設計でもあります。今までユースケースはどちらかというと顧客寄りの概念だったものを、今度はオブジェクトに紐づける。ここでオブジェクトを洗い出し、その上で大事なのは（ロバストネス分析は）シーケンスではない（シーケンスとは目的が違う）ですよと。シーケンスというのはクラスとかに紐づきますけど、クラスまでは特定してないです。

オブジェクトとユースケースを関連付け、ここの曖昧さを取り除く。このロバストネス分析があることで、初めてユースケース駆動は効力を増すので、それをレビューします。

最後は分析／予備レビュー。ここからテクニカルアーキテクチャというICONIXのプロセスに入ります。ここのテクニカルアーキテクチャから、またDDDの戦略設計に戻りましょう。

アーキテクチャやパッケージやコンポーネントの粒度を決めるCQRSを使う・使わないの非機能要件を決めます。テスタビリティ、コンテキストマップをどうしようか。そういうところにすんなり戻れるわけです。ICONIXで概念の洗い出しや足りない概念の考慮ができているので、よりDDDがうまくまわります。

ICONIXプロセスの一部を取り入れることによってDDDはより駆動するでしょう、というお話です。以上になります。ご清聴ありがとうございました。