すごく長いです。
ここから2、3年くらいは、仕事でAndroid アプリを開発している人はもっぱらメーカーのプリインアプリを作っている方たちで、多くの人は趣味でAndroidアプリを開発して、マーケットに公開していました。
彼ら、彼女らが作るアプリはほとんどが無料で、ユーザーは開発者自身、自分が欲しいもの、自分にとって便利なものをみな作っていました。
さらに趣味アプリの場合、コードをいじるのは自分だけです。今ほど github を使っている人もいませんでしたし、趣味アプリの場合、OSS として github 上に公開してもコミットするのは自分だけという状況は多いのではないでしょうか。
スマートフォンを対象に新たにサービスを立ち上げたり、すでに展開しているビジネスのクライアントとしてアプリを開発するというのは、趣味アプリとは前提が異なります。
ライバルのアプリに新しい機能が追加されたら、うちのアプリにも入れろと言われ、あれやこれやの施策をやりたいと言われ、しかも早くやれと言われる。開発するほうは大変です。
他の人が書いたところをすべて読まなくては機能変更ができない、という状況では困ります。
我々のアプリは危機に瀕している。
機能を満たすだけのコードが無秩序に積み上がった状態はまるでハウルの動く城。
あやまってネジを抜いてしまったら、全てが瓦解しかねない。
デグレの嵐、燃えるユーザーレビュー。
おそろしい。
よくわからないコードをいじる時はおそるおそる。すごく時間がかかる...
このままではいけない。
機能を満たすだけのコードが無秩序に積み上がった状態はまるでハウルの動く城。
あやまってネジを抜いてしまったら、全てが瓦解しかねない。
デグレの嵐、燃えるユーザーレビュー。
おそろしい。
よくわからないコードをいじる時はおそるおそる。すごく時間がかかる...
このままではいけない。
なんとかアーキテクチャや、なんたらパターンがあふれているけれど、どれもしっくりこない。 うまくいっているという話もあまり聞こえてこない。 もし技術的なパターンを適用するだけでうまくいくなら、今頃みんなそれをやっているはず。でも、そんなふうにはなっていない。 表面的な技術的パターンではなく、もっと本質的なことを考えるべきではないのか。
そのヒントを探してドメイン駆動設計の本を手に取りました。
ドメイン駆動設計の本といえばこれですね。
すごく分厚いです。3cmあります。
一人で読み切るのは大変だと思います。私は友人と読書会をすることで通読できました。
チームでDDDに取り組もうとするときには、少なくとも一人はこの本を読み切った人がいるべきだと思っています。 実は、この本は読みながら出てきた内容を順番にチームで取り組んでいけば良い、という構成ではありません。最後の方、第4節、14章に大事なことが書いてあるんです。
こちらのほうが説明の日本語がわかりやすいかと思います。
この本は実践とついているだけあって、チームでDDDに取り組むにはどうやっていけばよいかという視点から書かれています。
先ほど言及したエリック・エヴァンスの本の14章で扱っている内容は、2章、3章で取り上げられています。
「実践ドメイン駆動設計」のほうが、チームでDDDを学びながら順次取り組んでいきたい、という要求に的しています。
ただし、この本ではエリック・エヴァンスの本を読んでいる前提で詳細な解説がされていないところもありますから、結局は2冊とも読むべきだと思います。
本には次のように書かれています。
ユーザーはこのアプリをどのような領域に適用するのか。つまりこのアプリで何をするのか。アパートを検索するわけではありませんね。料理のレシピを検索します。つまりこのアプリのドメインは料理のレシピ、または料理そのものと言えます。
UberやLyftはどうでしょうか。適用する対象領域は「移動」と言えるでしょう。海を渡るためには使いませんからドメインは「近距離移動」でしょうか。
自分のアプリやサービスのドメインについて考えてみてください。
ドメインについて考えると、そこには実際に存在するものから概念的なものまでさまざまなものが含まれます。例えば、食材や調理器具や間取りや車など。
githubのようなソースコードを管理するサービスのドメインにはソフトウェアという概念が含まれるでしょう。
自分のアプリやサービスのドメインについて考えてみてください。
ドメインについて考えると、そこには実際に存在するものから概念的なものまでさまざまなものが含まれます。例えば、食材や調理器具や間取りや車など。
githubのようなソースコードを管理するサービスのドメインにはソフトウェアという概念が含まれるでしょう。
ユーザーだったり、同僚だったり、さまざまです。
例えば料理をするとはどういうことですかと聞くと、「材料を用意して、それぞれの分量を計り、手順に沿って調理していく」ことです。のような答えが出てくるでしょう。
なにやら「材料」というものがあって、それが複数必要なようだ。材料には「分量」というものがあって、「分量」というのは測るものらしい。さらに「手順」というものがあって「調理」というものをするらしい、と。
ドメインモデルは図を書いて説明したり、文章で説明したりできますが、図それ自体がドメインモデルである、というわけではありません。 あくまで頭の中の共通概念としてモデル化したものです。
ドメインエキスパートを含めたチーム全員が同じユビキタス言語を使います。
そのため、何をユビキタス言語とするかはドメインエキスパートを含めたチーム全員で議論して合意の上で決めます。
ユビキタス言語はドメインエキスパートと開発者、そしてチームの共通言語です。単なる用語集ではありません。言葉は進化し、育っていくものです。
ドメイン駆動設計の利点としてよく、コードが設計であり、設計がコードであるという点が挙げられますが、コードがドメインモデルを正確に表現していれば、それはすなわち設計である、ということです。
共通の概念モデルとしてドメインモデルを作り、それをコードで正確に表現するよう実装するので、他の人にとっても誤解しにくいコードになります。
じゃあ最初にドメインモデルを全部作り上げ、それから一気に実装すればいいのかというと、そうではありません。
最初から完璧なドメインモデルを作ることは不可能です。実装してみると、このモデルだとうまく実装できない、ということが判明したり、実装の途中でもっとよいモデルを思いつくことはよくあります。
つまり、アジャイル的なプロセスを前提としています。
まず、ドメインエキスパートの言葉を観察し、ドメインを構成するユビキタス言語を見つけます。
次にユビキタス言語を使ってドメインを適切に反映した、我々のソフトウェアに役立つドメインモデルを作ります。
そして、作ったドメインモデルを正確に表現するようコードを実装し、これを繰り返します。
ドメインモデルを作ってから実装です。いきなり実装ではありません。
そこで、ドメイン駆動設計では、実践するために役立つさまざまな手法が出てきます。これらは主に2つに分けることができます。
戦略的設計と戦術的設計です。
一方の戦術的設計には値オブジェクトやエンティティ、サービスなどがあります。名前を聞いたことがあるという方もいるでしょう。他にも集約やドメインイベントやリポジトリなどもあります。
このようなコーディングにおける技術的な手法は理解しやすいため、ここだけを取り入れてみました、という話がよくありますが、これは完全なDDDではありません。
なぜか。ドメインモデルがないからです。
ここでちょっとドメイン駆動設計が何でないかの話をしたいと思います。
違います。Clean Architecture を知らないという人は気にしなくてよいです。
もちろんDDDとClean Architectureを組み合わせて使うということは可能ですし、Clean Architecture のコンセプトはDDDの影響を受けている、参考にしているということはあるでしょう。しかし、ここで言いたいのは DDD = Clearn Architecture ではない、ということです。
これも違います。今までの話の中でビューはでてきましたか？出てきてませんね。我々が話してきたのはドメインモデルについてだけです。
エリック・エヴァンスの本でレイヤ化アーキテクチャが紹介されているからか、DDD=レイヤ化アーキテクチャにすること、のように勘違いしているのを見かけることがあります。ドメイン駆動設計とアーキテクチャの関係はこのあと取り上げますが、ドメイン駆動設計は特定のアーキテクチャに依存しているものではありません。
ドメイン駆動設計ではドメインモデルを作ってそれを正確に表現するようにコードを実装することであって、特定の技術的パターンをとることではありません。
これが正解です。
簡単に言うけど、やるのは難しいんだよね。
Androidアプリ開発でドメイン駆動設計に取り組む場合も同じです。ドメインエキスパートの話を聞いて、概念を適切に反映するドメインモデルを作って、それを正確に表現するよう実装する、これを繰り返します。
そうは言われてもどこから手をつけたらいいかわからない。
アプリにはいろいろ機能があるし、どれをやるべきなの？
また知らない単語がでてきました。
境界づけられたコンテキストとコンテキストマップ。
先ほど戦略的設計で名前が出てきました。この2つもドメイン駆動設計の重要な要素です。
境界はわかります。コンテキストとは何でしょうか。日本語ではよく文脈などと訳されますね。Androidでよく出てくるあのコンテキストではありません。
ユビキタス言語の言葉が特定の意味を持つ領域がコンテキストです。
ユビキタス言語を構成する言葉が特定の意味を持つ領域がコンテキストであり、
境界づけられたコンテキストの内部では、ユビキタス言語を構成する言葉は特定の意味を持ちます。
どういうところが言葉の境界になるのでしょうか。
いずれ、ドメインモデルを境界内で厳密に一貫性のあるものに保つことができなくなります。
だからといって正確に把握したものでなければならないというわけでもありません。最初はわかっている範囲で十分です。状態が変わったり、新たな知見が見つかったらその都度マップを更新しましょう。
凝ったつくりにする必要もありません。ホワイトボードに書いたものを写真で撮れば十分です。
依存する他のプロジェクトに何があって、それとどのような関係なのかをチームで共有し、考えるきっかけにします。
作ったマップはいつでも見れるところに置いておく。Activityのライフサイクルポスターの横に貼り出すなんて最高ですね。
そしてコンテキストマップのコンテキスト同士をつなぐ線にどのパターンなのかを書いてみましょう。
パターンに名前がついていることは、とても重要です。後からチームに参加したひとでもコンテキストマップをみることで、どの依存プロジェクトが協力的で、どこが融通がきかないのか把握することができます。
いくつかのパターンをAndroidアプリ開発でありそうな状況にあてはめてみます。
よくわからないですね。ようはこういうことです。
あるサブシステムとやりとりしたい人が複数います。
それぞれに個別に対応するのは大変なので外部に方法を公開するよということです。方法はRESTかもしれないしRPCかもしれない。
別のコンテキストのモデルによって自分のドメインモデルが汚染されないように、必要に応じて自分のコンテキスト内のモデルに変換します。なので、この変換はコンテキストの外側にあることになります。
OHS は公開ホストサービス、PL は公表された言語、ACL は腐敗防止層です。
公開ホストサービスに限らないのですが、サーバー上のサービスが提供しているコンテキストとアプリのコンテキストが異なるのであれば、モデルの変換が必要になります。
別のコンテキストの userInRole をそのまま利用側のコンテキスト内で使うのではなく、利用側のコンテキストに存在するドメインモデルである Moderator に変換して利用します。
ユビキタス言語がDDDを行っていくうえで重要な要素であることを理解しました。
境界づけられたコンテキストを見つけ、コンテキストマップを描きました。
次に考えることはなんでしょうか？
それはドメイン層を隔離することです。
なぜ我々はユーザーインタフェースに、ドメインにある概念や知識、ビジネスロジックを詰め込んでしまうのか。
それはアプリの作り方に深く関わっています。
その利点には次のように書かれています。
・単純なアプリケーションの場合、生産性が高く、すぐに作れる。
・それほど有能でない開発者でも、この方法なら、ほとんど訓練しないで仕事ができる。
・要求分析が不足していても、プロトタイプをユーザに公開し、その要望を満たすように製品を変更することで、問題を克服できる。
などなど
この利点が利点として生きる場所があります。モックやプロトタイピングです。
モックやプロトタイピングでは、画面のデザインを動くもので素早く確認するのが目的ですから、単純なビジネスロジックも含めすべてユーザーインタフェースに入れます。
つまり、動くアプリをすばやく作ってユーザーに見せて検証したい、という場合、利口なUIになりがち、ということです。
ありがちな状況ですが、画面デザインと単純な機能を短い期間で作ることを求められる状態でも利口なUIになりがちです。
理想を言えば、機能について議論するところから開発者も参加して、みんなの頭のなかにある概念的なモデルについて観察し、ドメインモデルを作りたい。
でもいきなりそんなこと言われてもできないよ、ってなりますよね。
重要なのは利口なUIになりがちだと認識すること。そして、ドメインにある概念や知識、ビジネスロジックがUIに存在していないか観察し、ドメインモデルとしてUIから隔離できないか考えることです。
ただし注意してほしいのは、ユーザーインタフェースからビジネスロジックを単純に隠蔽することと、ドメインモデルとして隔離することは違います。
Activityとライフサイクルを同期するようにした、なんたらプレゼンターみたいな名前のクラスを作って、そこに処理を全部移譲することではありません。
大事なのはドメインモデルです。ドメインを反映したドメインモデルを作ることで、ユーザーインターフェースからビジネスロジックを引きはがせないか考えましょう。
次にドメインエキスパートと会話をしてドメインを構成する言語を見つけ、ユビキタス言語として確立し、育てていく必要があることがわかりました。
そして、言語の境界がコンテキストの境界になり、アプリにはそれを構成する境界づけられたコンテキストが複数存在することがありえるということをみました。
コンテキスト同士の関係をコンテキストマップとして描くことで、どのような関係性がコンテキスト同士の間にあるのか把握できるようになりました。
重要なのは、これらの技術的なパターン、手法は「ドメインモデルを正確に表現したコードを実装する」ためのものです。表現したいドメインモデルがないのに、技術的なパターンを真似してもドメイン駆動設計の恩恵は限定的です。
なんとなく理解したけどコードが出てこないとやっぱりよくわからない。 私もそうです。言葉だけで理解するのは難しい。
というわけで、ここからはおまけです。
このコードには2つ問題があります。
体重というものについて考えてみてください。体重の概念にマイナスというものはありますか？私の体重マイナスですっていうかたいますかね？いたとしたら多分その人は反物質でできているんだと思います。 ここで大事なのは科学的にありえるかどうかではなく、ドメインについて考えることです。動物の体重という概念を反映したドメインモデルを考えるとマイナスという状況はないですよね。
ではどうするか、体重を反映したドメインモデルを作るんです。そのモデルは浮動小数の値を持っていて、その値はマイナスではない。いや、マイナスではないというより 0 より大きいと考えるほうが適切ですね。
Weight オブジェクトのインスタンスから取得した体重の値は、必ず 0 より大きい。つまり体重に対するドメインモデルを表現できています。
注意してほしいのが、未入力を -1 で表すか null で表すかという話ではない、ということです。
ドメインにおける体重というものについて考え、それを反映したドメインモデルを考え、Weight クラスというドメインオブジェクトとして表現する、という話です。
このコードにも問題がありますね。
なんでこんな実装になっているのか聞いてみました。
「サーバーのレスポンスが文字列だったので...」
なるほどーーーー。
UIが文字列の意味を知ってるのは変だから直してみてくれる？
そういうことじゃないんだ...
UIがどのユーティリティメソッドを使って判定するか知っていなければならない、結局UIが賢い問題は解決していない。
必要なのはドメイン、つまり性別について考えることです。
我々の頭のなかには性別という概念的なモデルがあるのだから、それを表現するドメインモデルを用意しましょう。
このドメインモデルをコードで表現するなら enum でよさそうです。
そこで出てくるのがコンテキストの統合で紹介した腐敗防止層です。
ここで、サーバーのレスポンスをアプリのコンテキスト内のドメインモデルに変換します。
ドメイン駆動設計について多少なりとも理解いただけたでしょうか。
まずはドメインについて考えるところから始めてみてください。
技術的なパターンだけとりあげたブログなどがよくありますが、表面的なことを真似しただけでうまくいくようなそんな簡単なものではありません。
例であげたようなシンプルなドメインモデルからでいいのです。ドメインを反映したモデルを作るという本質に取り組んでほしいです。
行き当たりばったりの設計に、とりあえず動けばいいやで作られたアプリを長年メンテナンスし機能追加するほうがよっぽど恐ろしいです。
シンプルなところからぜひドメイン駆動設計の本質を取り入れてみてください。
0 件のコメント:
コメントを投稿