（講演ではアドリブもあるので原稿とは微妙に異なることをご了承ください）
追記 : 前回の内容を読んでいない方は、先にそちらを読んでください。
本当は前回のCfPを出す時点でAndroidアプリ開発での実装の話もいれようかなと思っていたのですが、ドメイン駆動設計が何かをきちんと説明するだけでいっぱいいっぱいでした。
今回は前回の続きなので、簡単に前回の復習からはじめます。前回の話の完全版は私のブログに書いてありますので、ぜひ読んでください。
ドメインエキスパートの言葉を観察し、ドメインを構成するユビキタス言語を見つけ、
ユビキタス言語を使ってドメインを適切に反映した我々のソフトウェアに役立つドメインモデルを作り、
作ったドメインモデルを正確に表現するようコードを実装し、
これを繰り返してドメインモデルと実装の両方を洗練させていく設計手法です。
究極的にはコードを読めばそのドメインモデルがわかるし、そのドメインモデルを理解しているならエンジニアじゃなくてもなんとなくテストコードが読めるという状態です。
じゃあ具体的にどうすれば、ドメインモデルをそのまま表現した実装にできるのかなって思いますよね。
それが戦術的設計です。
例えばドメインイベントは、エリック・エヴァンスの本が出版された後に新しく付け加えられています。
戦術的設計のパターンはたくさんありますから、すべてがAndroidアプリの実装に役立つとは限りません。
例えば、実践ドメイン駆動設計にはMongoDBやSpringでの例が出てくるパターンがあるのですが、Androidアプリの開発に置き換えて考えるのはなかなか難しいです。
よって、この講演ではこれらを網羅的に紹介したりはしません。
という方に向けて
作り直すときの話ではありません。
いままで5つ以上のアプリで、ドメイン駆動設計をどう取り入れるか試行錯誤してきました。
複雑に絡み合ったアプリのコードを少しづつ紐解いて、UIに隠されていたドメインモデルを実装としてどう表現してきたかという話です。
こういう方法よかったよと言う場合、無条件にすべてに適用できるものではありません。どういう状況のときによかったのかをはっきりさせておかないと、お互いに不幸になります。
特にドメイン駆動設計はさまざまなソフトウェアの開発で取り組まれていますから、同じ戦術的設計のパターンであっても、対象とするドメインだけでなくプラットフォームやフレームワークによっても最適な実装が異なるでしょう。
この講演で紹介する実装例は、以下の状況を前提としています。
まず、Androidアプリの開発での話です。iOSアプリやサーバーサイドの開発には参考にならない可能性があります。
次に、少なくとも1年以上継続的に開発しているアプリを前提としています。
これは「ある程度モデルらしきものがメンバーの共通認識としてあり、コードにもそれっぽいものがあるが、ドメインモデルとしてコードでうまく表現されていない」という状況になるには1年ぐらい必要かなと思ったからです。実際にはもっと年数の経っているアプリで取り組んでいます。
そして重要な前提条件が、サーバーとAPIを介してやりとりする、よくあるクライアントアプリであるという点です。ゲームアプリなどにはあまり参考にならないかもしれません。
サーバー側が別チームというのは、前回お話した境界づけられたコンテキストに関係する部分です。サーバーとアプリで別の境界づけられたコンテキストになっているという状況です。
では、さっそく本題に入りましょう。
前回の話で、「ドメインを隔離する」というのは
本では次のように書かれています。
ここでのドメインロジックは、ドメインモデルに属するロジックのことです。ドメインモデルに関連するロジック、ドメインが持っているロジックとも言えます。
例えば、ドメインモデルに属するロジックが UI に書かれていると、ドメインモデルをそのまま表現した実装にできません。
そうすると次は、どうやって隔離するのか、です。
本では次のように書かれています。
この文章は前回も紹介しました。
好きな方法でやればよいのです。なので前回は具体的な方法は紹介しませんでした。
エリック・エヴァンスのドメイン駆動設計を読んだ方なら、じゃあアレはなんなんだ、と思うかもしれません。
方法は問わないと言っているのに紹介しているなら、その理由は簡単です。
いきなりドメインを隔離しろと言われても、具体例がないとなかなか理解できないものです。
つまり、ドメインを隔離できそうな設計としてこういうのがあるよ、という例としてレイヤ化アーキテクチャが紹介されている、ということなんです。
ただし、方法については次のようにも書かれています。
単に置き場所を分ければいいというわけではなく、他の部分と疎結合できるようになっている必要がある、というわけです。
利口な UI から脱却するにはぜひともドメインを隔離したいところ。
UIはドメインを知っているが、ドメインはUIを知らないようにしたいということ、
ドメインと他の部分を疎結合にしたいということ、
そして、それを強制させたいということです。
単純にパッケージを分けるだけだと、ドメインからUIのクラスを見ようと思ったら見えてしまいます。
見ないように気を付けようだと形骸化します。メンバーが変わった時だけでなく、リリースに間に合わせるために今回だけ特別、みたいなことが容易に想像できます。
このモジュールは gradle のモジュールのことです。
また、UI を変更してもドメイン部分に変更がないのであれば、その部分の動作を担保できますし、ドメインモジュールのリビルドが走らないのでちょっとだけビルドが速くなります。
いや、入れるのはドメインモデルってのはわかってる。
わからないのは、自分のコードの中でどれがドメインモデルであるべきなのか、どこから見つけていけばいいのか...
そこで役に立つのが次の戦術的設計のパターン、「値オブジェクト」です。
概念的な同一性を持たない、というのは、一意に識別する必要がない、区別する必要がないということです。
同じ色を持つ Color オブジェクトを区別する必要はありませんよね。
ドメインモデルの中には、このような「何であるかだけが問題となり、誰であるかやどれであるかは問われないような要素」がでてきます。
これらを値オブジェクトとして実装することで、ドメインモデルを表現した実装になります。
値オブジェクトの他の面も見てみましょう。
不変であれば自由にコピーや共有ができ、複数のスレッドで安全に利用できます。また、引数や戻り値として別のオブジェクトに渡しても、その先で変更されないので設計の簡素化につながります。
この話を聞いて、なんか聞いたことあるなと思った方いらっしゃると思います。このイミュータビリティの話は Effective Java でも紹介されています。
さらに別の面も見てみましょう。
概念的な統一体...ちょっと難しいですね。
このとき、郵便番号、都道府県、残りのアドレスは、ユーザーの別々の属性ではなく、住所という統一体を形成する属性です。
よって、この3つで形成される住所という値オブジェクトを用意し、ユーザーには住所を持たせるようにします。
つまり、値オブジェクトとなるドメインモデルを見つけるところから始めるのが最適ということです。
いやいや、そうは言っても、Color とか Android フレームワークにあるし、値オブジェクトにするもの見つかるかな？
そんなあなたのために、今回は Android アプリの開発で値オブジェクトとしてモデリングした例をたくさん用意しました。
状態を不変に保つ、つまりイミュータブルにできる
値が等しいかどうか比較できる
全体を完全に置き換えられる
に注目すると、
Java ならフィールドを全て final にして equals() と hashCode() を override するか、AutoValue などのライブラリを使うという手もあります。ですが、これを機に Kotlin を導入してみてはいかがでしょうか。
この ID を値オブジェクトにするとどうなるか、最初の例を見てみましょう。
フォロワー一覧画面を作るとき、このAPIを呼び出す側も呼び出される側も同じ人が実装すると、何を渡せばいいのかわかっているので String であっても特に困ることなく実装できます。
後になって、別の人が他の場所からこのAPIを呼ぶことになったり、機能を変更することになったら、次のような問題が出てきます。
userId が空文字になるわけないんだけど、でも Profile が持ってる id に空文字が入らないなんて他の部分も読まないと保証できないし...
UserId のインスタンスがあるなら、それが保持している文字は絶対に空文字ではないと保証できる状態にします。
こうすれば、利用側は安心して getFollower() API を呼び出すことができます。
Profile クラスが持っている id が UserId 型なら、この API に渡してよいいIDであることが明白です。
さらに String から UserId 型にすることで、どこで利用されているかを静的に解析でき、リファクタリング時の影響範囲も調べやすくなります。
例えばアプリの中に categoryId というのがあったので、値オブジェクトにしようと思って利用箇所などを調べていると
この ID 用の値オブジェクトを用意するにはクラスの名前が必要です。この名前はユビキタス言語になるものです。
そこで、どちらをユビキタス言語にするか話し合って GenreId に統一しようということになりました。
ID を値オブジェクトにできないか考えたことで、言語の問題に気づけ、チームとして新しいユビキタス言語を見つけることができました。まぎらわしい変数名がつけられるのを防ぐこともできます。
商品画面からブランド一覧画面に遷移するために、商品 ID の文字列を処理してブランド ID 部分を取り出すようになっていました。
id が空文字だったり : を含まない文字列だったら、意図しない値で BrandActivity を開くことになる、という問題もありますが、
もうわかりますね、
正しいフォーマットから ProductId が構成されることを保証できますし、UI 側は商品 ID の文字列表現がどうなっているかを知らなくてすみます。
では次の例に行きます。
性別と生年月日を渡す必要があります。
性別ってどんな文字列送ればいいの？
というか、そもそも扱いたいのは性別そのものであって、性別を表現した文字列じゃないよね。ということは性別はモデルでは...
同じ性別なら、性別として区別する必要はないのでこれも値オブジェクトです。
しかし、まだ問題があります。
こちらも考えてみましょう。
同じ日を指している日付は区別する必要がないので、値オブジェクトとして表現できます。
誕生日など特定の意味をもった日付はドメインモデルです。
どういうフォーマットで文字列にするのかを UI から隠蔽できます。
判定処理の重複はなくなりましたが、ドメイン駆動設計としては問題があります。
ロジックが誰の責務なのか考えるの難しいですよね。私も迷うことがよくあります。この例にしても、wide かどうかの情報は placeholder を使い分けるために使っているから、UI のロジックであってドメインのロジックではないのでは？と思うかもしれません。
この例では Image に置きましたが、表現するドメインモデルが異なれば異なる実装になるでしょう。画一的は判断基準はなく、頭の中のドメインモデルにとって自然かどうかだけです。 wide かどうかという属性は Image というドメインモデルにとって自然かどうか。
最初からしっくりくる実装ができないことはよくあります。大事なのは、その実装で固定化せず、よりよい方法が思いついたときにリファクタリングする、できるようにしておくことです。
このとき、JSONやXMLの構成をそのまま反映しただけのクラスにしていませんか？
さぁ、このロジックをどこに置きましょうか？
このような状態は、先ほどと同じドメインモデル貧血症ですね。
ところが問題が起こります。
Item と Category に同じロジックが重複することになってしまい、よくありません。
JSON の形式を一旦忘れて、「表示する領域の大きさに応じて適切な Image を選択するロジック」は誰の責務なのかを考えましょう。
本当に Item の責務なのかな？
適切な Image を選択するロジックの置き場所として自然な感じがしませんか？
各お知らせにはバナーが含まれている場合があり、バナーには表示期間の開始日時と終了日時があります。
これを使うとしたらどうでしょう。
bannerImageUrl は null じゃないけど、bannerStartDate が null のときはどうするの？って思いませんか？
banner のインスタンスがあれば url も日付も揃っているということを保証できます。
アイテムにはログインしていなくても使えるものや、ログインしていれば使えるもの、有料会員になっていれば使えるものなどがあり、サーバーからは複数のフラグが返されます。
昔は2種類しかなかったなど、歴史的経緯とか拡張とかで、こういうレスポンスになっています。
UI 側で if 文を駆使した処理が行われていることは容易に想像できます。
ここでも一旦レスポンス形式のことを忘れましょう。
アイテムをドメインモデルとして考えると、アイテムの属性として自然なのは個々の Boolean よりも、どういうアイテムなのかという種類です。
次にすることは、ドメインエキスパートに話を聞きに行くことです
Boolean の組み合わせは16パターンあるのに、アイテムは5種類しかないということは、ありえない組み合わせや縮退している組み合わせがあるということです。
判明した種類を元に、サーバーチームにどういうときにどういう値が返ってくるのか確認しましょう。
isMemberUsable は都度課金用のアイテムができたときに isPurchaseRequired と一緒に追加したので、isPurchaseRequired が true のときしか意味ないです。
とか、
などの情報が得られました。
腐敗防止層ですよ。前回出てきましたね。
しかし、モデルの中には同じ属性値であっても区別が必要なものがあります。例えば、AさんとBさんが同じ山田太郎という名前であっても、別の人として区別が必要です。
このようなモデルを表現するオブジェクトとしてドメイン駆動設計にはエンティティという戦術的設計パターンがあります。
本ではこのように書かれています。
人間には同一性があります。例えば年齢や見た目が変わってもAさんが同じ人だと認識しますよね。
エンティティにはライフサイクルがあります。人がその一生の間に変化していくように、ライフサイクルの間にエンティティの内容は変わることがあります。そのとき、新しく作られるのではなく、以前の内容が変わったという連続性が維持される必要があります。
これらは技術的な制約と関係することもあり、エリック・エヴァンスのドメイン駆動設計でも実践ドメイン駆動設計でも具体的な実装を出して議論されています。
Android アプリでも、スタンドアローンで、マスターデータをアプリ内のデータベースに保存するような場合には、これらをどう実装するかが問題になります。
しかし、マスターデータがサーバーに保存され、識別子もサーバーで発行されるクライアントアプリでは、これらをアプリ側で行うことがありません。
UserId で一意に識別すべき User なら、UserId で識別するよう equals() と hashCode() を override すべきでしょう。
Android アプリでのエンティティの扱いについてはまだまだ試行錯誤中で、例えば SharedPreferences に保存している、初回起動かどうかのフラグや通知を受け取るかどうかの設定はエンティティなのか、など悩みはつきません。
この話は機会があれば次回できるといいなと思っています。
同じ属性値をもっているなら区別する必要がないモデルは値オブジェクトとして表現できるということを紹介しました。
属性は不変にし、値オブジェクト自体を差し替えることで変更に対応しましょう。
モデルに属するべきロジックを持たせましょう。モデルの表現として、条件を満たしているときだけインスタンス化しましょう。
サーバーのレスポンス形式は時としてモデルをうまく表現できていないことがあります。それに引きづられてドメインモデル貧血症になっていませんか？一旦レスポンス形式のことは忘れて、どういうモデルがあるべきかを考えましょう。
