ソフトウェア開発メモ

日々のソフトウェア設計、実装で考えている、気づいた事を書いています。それが真実か否かは保証しません。悪しからず。

iOSアプリでのドメイン貧血症について

iOSアプリでのドメインモデル貧血症について、自分なりに考えた。ここでいうドメインモデルはDDDで言うエンティティの事である。iOS固有の話であって、他のプラットホームについては知りません。

 この問題の趣旨の通り、ドメインモデルにやらせる仕事はドメインモデルのメソッドとして実装するのは本筋だろう。仕事をするのに必要な属性を持っているのだから。

ただ、 Viewにモデルの属性を表示させる場合、どうしてもView内のメソッドにモデルの属性から値を取り出して、ビューにその値を代入する処理を実装しないといけないだろう。

 

もしモデルのメソッドとして持つ場合、

  •  MVCの禁じ手であるモデルがビューと結合してまう。
  •  ViewとModelが循環依存の関係になる。Viewがいつモデルの監視を辞めるかはViewしか知らない。一方、モデルのメソッドにはViewの属性にアクセスするコードが表れる。
  •  モデルが各ビューのバインドメソッドを保持する実装になってしまう。モデルとして自律できなくて個々のアプリケーションにがっちり結合してしまう(カテゴリーで逃げる手は無くないけど)。

 

と言った所かな。

 

  REST通信の返答メッセージからエンティティを組み立てる場合も同様に応答メッセージクラス?からそのパラメータをエィティティ の各属性に反映するメソッドとして実装しなければいけないだろう。でないとエンティティに応答メッセージのパラメータからエンティの各属性値に変換するメソッドを自身に抱え込んでしまう。

  結論からするとエンティティ同志で閉じる処理以外はどうしても他のクラスに属性を公開しないといけなくなり、ドメインの健全性を完全に保つのはむずかしいい。現段階での自分なりの最善策は、属性の公開範囲を限られたクラス内に限定する事だろう。

 

 読んでいる人はチンプンカンプンだが自分の頭の中が整理できたからいいか。

※気が向いたらソース付で説明します。