AndroidアプリにDDDを適応する-戦略的設計-

2020-06-06 Android DDD

はじめに

ビジネスに適応するソフトウェアを作るにはどうすればいいのか模索している中でDDDの存在を知りました。
勉強がてら個人のAndroidアプリ開発でDDDを実践しようとしましたが、技術的なパターンを取り入れてはいるものの
どこかしっくりこず、DDDへの理解が深まらない中でアプリ開発を進めている状況でした。

そんな中でAndroidアプリへのDDDの適応方法を調べていて参考記事に出会いました。

参考記事

作ろうとしているアプリ

ついつい無意識にいじってしまうスマホ、どのくらいスマホに依存しているのか？
依存度を可視化してみようという大義名分の元にスマホの使用回数がわかるアプリを作ります。
実は裏テーマがありますがここでは伏せておきます😂

DDDの戦略的設計の流れ

  1. アプリのドメインについて考える

  2. ユビキタス言語を育てる

  3. 境界づけられたコンテキストを見つける

  4. コンテキストマップを描く

  5. アーキテクチャの検討

アプリのドメインについて考える

改めてドメインとは何か？
ドメインとはソフトウェアによって解決したい「問題領域」のことである。
要はユーザーがアプリを利用する対象領域と考えることができる。

ユーザーがレシピ検索アプリを使うのは「レシピ検索をしたい」からであり
そうするとドメインは レシピ検索 だと考えられる。
レシピ検索ドメインの裏には 美味しい料理を食べたい という問題提起が背景にあるかな？
とか思ったが、ドメインを考える前の話な気もするのでここでの深堀はやめておく。

個人のAndroidアプリ作成時にやりたいことを考えた後にいきなりユビキタス言語を探しており
なかなかユビキタス言語を見つけられなかった(しっくりこなかった)が、この工程が抜けていた。

実践

ユーザーはスマホの使用率・使用回数を知りたい時に本アプリを利用します。
そのためドメインは「スマホ使用率の確認」になります。
スマホ使用率の定義は迷いましたが、今回は「ホーム画面を表示した回数」としました。
ついつい用もないのにホーム画面開いちゃう、あれって完全にスマホ依存ですよね・・・

ドメインについてしっかり考えないと不要な機能作っちゃったり、やりたいことから
それてしまうなと思いました。

ユビキタス言語を育てる

実践

現段階で思いついたのは以下です。

スマホ使用率(＝ホーム画面の表示回数)
 - 記録する
 - 確認する
 - リセットする
履歴
 - 記録する
 - 確認する

境界づけられたコンテキストを見つける

言語の境界がコンテキストの境界になる。
ユビキタス言語が通じる範囲だと考えると自分が考えていたパッケージ構成だと
わかりにくいという気付きがあった。
境界づけられたコンテキスト(個人のアプリでは機能単位になりそう)毎に
パッケージを作成し、その中でdomainパッケージなどを作成する構成にしてみよう。

実践

  • スマホ使用率コンテキスト

  • 履歴コンテキスト

スマホ使用率コンテキストだけで大義名分は果たせそうな気もするのですが
コンテキストが1つだけだと学習のテーマ的に物足りないので履歴コンテキストも足しました。
まあ裏テーマではこの履歴が大事になるので必要なコンテキストになります。
機能追加していく時にコンテキストは増えていくのだろう。

コンテキストマップを描く

境界づけられたコンテキスト間の関係性を図化したものがコンテキストマップである。
サーバとの通信やDBといった技術要素に引っ張られて、やりとりする先の事情が
ドメイン知識を汚しがちになっていることに気がつけた
例えば、サーバからのレスポンスが文字列だからドメインオブジェクトでも文字列として
扱っていると表現力が乏しくなる。
そういった時は腐敗防止層を取り入れてドメインオブジェクトへの変換を行うようにしてみる。

実践

hugoでの画像の挿入がうまくいかなかったから画像は省略・・・

DBとの間に腐敗防止層を設けるべきか？それをコンテキストマップ上で表現すべきか？
については自分の中に指針がないので勉強しながらどうすべきかを模索していこうと思います。

アーキテクチャの検討

DDDはアーキテクチャに依存しない。
やりたいことはドメインを隔離することであり、その手法としてレイヤードアーキテクチャがある。

Androidアプリ開発でよく聞くFatActivityはドメインがUIに記述されてしまいおきている。

Smart UI

なぜUIにドメイン知識やビジネスロジックをつめこんでしまうのか？
それはアプリの作り方に関わってくる。

SmartUIのメリットをみていくとイメージが掴みやすい。
* 単純なアプリケーションの場合すぐに作れる * Frameworkに従うだけで訓練していない人でも作れる

上記なようなメリットがあるため、人は楽な方に倒しがちなのでFatActivityなどが
生まれてしまうんだなと思いました。
UIは利口になりがちだと認識した上でドメイン知識にUIの事情を混入させないように意識してみます。

まとめ

テーマが簡単かもしれませんが、DDDの戦略的設計はこんなところでしょうか。
次回は戦術的設計に入っていきたいと思います。

Relevant Topics