調べ物した結果

現役SEが仕事と直接関係ないことを調べた結果とか感想とか

SpringFrameworkとドメインオブジェクトとのかかわりがなんだかわからなくなってしまった


いまだに釈然としてないしわかってないのだけれど。
.NetおじさんだったけどSpring使うことになり。今までとなにがどう違うのかわからん。わからんスーパーわからん。
説明受けたけどやっぱりなんか気持ち悪いところがあったりしたから吐き出す。
3層アーキテクトでいくぜい。てきなことを言われはしたが。文書にすることでちょっとはましになるかなーと思って書く。

とりあえず3層

データソースそう

リポジトリの置き場所。

プレゼンテーション層(ユースケース層)(@Controller)。ここはOK.だいたい分かった。

あんまり飛び道具的なものがなさそうなのでちょっと安心。Controllerとドメインオブジェクトとのつながりが怪しい。
Thymleafを使うのだけれど。
Thymleaf(HTML), Model, Bean, ModelAndView。この辺が頭の中でごちゃごちゃしてる。
Controllerの役割はHTTPリクエストのマッピングだとおもっている。
後述Serviceを細かく分けたときの組み立てもService(Scenarioクラス)に任せる。
これを書くまで、ここに直接サービスから受け取ったドメインオブジェクト渡せばよいとおもってたけど。
・表示は「ドメインオブジェクト」の仕事じゃない。
ということが守れなくなるのでやめたほうがよさそう。
結構責務がおおい。命名規則なので責務がわかるようにしたい。

アプリケーション層(@Service)。ここの解釈がだいぶ混乱した。

とりあえずServiceという名前からAPIのようなイメージでURL投げるようなイメージをしてしまって混乱し、
Serviceといっているのみ業務ロジック(BL)の置き場所。というような説明をうけさらに混乱した。
そーゆーときもあるのかもしれない。けどここでのサービスはいわゆるドメインオブジェクトに対するサービス。でよさそうだ。
どのドメインオブジェクトの責務にするにもちょっと落ち着かない。そんなものが置かれる場所。
この辺りで3層アーキテクトではドメインオブジェクトの置き場所がないのではないかと気づく⇒てきとうに読みあさってもどうやらあっている。

おわり

全体的に、アノテーションの言葉通りに受け取るのがよさそう。信じてるぜSpring
あと、一回読んだ本も実体験をうけて切羽詰まると読み込みが違いすぎる。やはり業務で経験するのは大事。

参考書
ドメイン駆動設計 モデリング/実装ガイド
・現場で役立つシステム設計の原則