きっかけ
尊敬するエンジニアの一人 @nobuoka さんのつぶやきがきっかけ。
常々自分も同様のことを考えていて、基本的には賛成。
しかし実際の開発においては 「(複雑な場合 は持たないとつらいなぁ)」 という実感があり、話してみるとnobuoka先生も同様の実感をもっているもよう。
今回はその 複雑な場合 とは実際どんな場合なのかを考えてまとめてた。
注意
この手の議論は燃えやすいので、しっかり前置きしておきます。
ここに書いてある考えが絶対的に正解とは自分自身考えてないです。こう言う風に考えてますと言う段階です。なにか引っかかること、疑問や多少議論してみたいなどあれば @kgmyshin までメンション投げてもらえれば、応えられるときは応えます！
ただし、SNSで議論することをあまり好んでないので、がっつり議論したい方はぜひ弊社に入社をば！一緒に楽しく議論しながら開発していきましょう！！
そもそもの前提となる自分の考え
たとえば、コンテキストマップが下記のようになっているサービスを考える。
このサービスをクライアントをつくるとなった時コンテキストマップはどうなるか。
システムが全く違うので下記のように一つのコンテキストと捉える場合もあると思う。
ただ、クライアント自身が意味のあるコンテキストを持っている訳ではないので、一つのコンテキストとして扱うのではなく必要なコンテキストを写した像のように考えた方が筋が良いのではないかと考えている。
クライアント自身が意味のあるコンテキストを持っている訳ではないからだ。
各コンテキストを拡張して一つのシステムにおいたものがクライアント だと考えている。
ドメインモデル持つべきか？
ここからが本題。どんな場合に持つべきなのか整理して行く。
持つべき場合
サーバーの構成を知らない場合
サーバーの構成やコンテキスト関係がどうなっているわからない場合はクライアントでもドメインモデルを持つべきである。
そもそもサーバー側の構成をクライアントが知る必要はないという意見も正であると思う ので、この理由ひとつだけで 持つべき としてもいいかもしれない。
コンテキストの統合がクライアント内で行われる場合
コンテキストの統合をクライアント内で行う場合がよくある。この場合はドメインモデルをクライアントで作らざるを得ない。
また複数にコンテキストをまたがる場合、コンテキストの統合はエンハンスして行く中で頻繁に発生しうるので初めから各コンテキストでドメインモデルを持っておくべきかもしれない。
オフラインでも動くことを保証される場合
オフライン時、上記のようにサーバー側がなくても動くことを求められているのでドメインモデルはクライアント側でも持たなければならない。
持つべきでない場合
逆に持つべきでない場合に触れておく。
クライアントでは一つのコンテキストしか扱わない
この場合は基本的に単純なクライアントとなるのでドメインオブジェクトを作る必要性はないでしょう。
単純なRSSリーダーなどがここに当てはまると思います。
まとめると...
いろいろ書いたが、 複数のコンテキストにまたがるアプリを作る場合は コンテキストの統合が後々発生した場合に対応するために、 クライアントにもドメインオブジェクトを持つべき 、という判断基準が個人的には妥当だと考えている。 (もちろん例外はあるが)
つまるところ、上に書いた〈複雑な場合〉はもう少し具体的に言うと〈複数のコンテキストにまたがるアプリを作る場合〉だったということになる。