Service層 - 山奥通信増刊号

Service層っていう言葉が、割と都合よくつかわれているというか、Facade兼コンテキストに応じたインタラクションの実装とか、別にService層=スクリプト的な記述にするわけじゃねーしとか(・ω・)

HogeServiceという名称の「ファサードと思いきやデータアクセスコンポーネントも兼ねるモノシリックなクラス」だけでレイヤを構成しているケースも多いんだろうけど。
単純なアプリだと、それでも困らないから(・∀・;) *1

サービスとはレイヤ(ビジネスレイヤ)であって、クラスではなく。
クラスで言うなら、アプリケーションファサード、コアドメインロジックを実装する(PIな)エンティティ、ビジネスコンポーネントなんかからなるものよね(・ω・)

自分の周りでは、ファットななんちゃらとかの話は、昔からプレゼンテーションのパターンの話と同時にレイヤの話をしているので、そう言うほどには見ないけど。
けど、アプリケーション層とドメイン層の分離が屑いというケースは見るかぽね(・ω・)

あと、もう2013年なんだし、ドメインモデルvsトランザクションスクリプト的な話はもういいでしょう、的な。
それって単にパターンの拡大解釈や、レイヤやファサードの話との混同だったりもするし(・∀・;)

っていうか、(国内では)なんでその部分の議論だけが流行っちゃったんですかね(・ω・)？
PoEAAだけで(アプリケーションアーキテクチャの話ではなく)ドメイン回りのアーキテクチャ設計まで語ろうとしたからかしら(・ω・)？

っで、この辺の議論が落ち着くのはドメイン駆動設計の翻訳まで待つことになったのだ…(・ω・) *2

あと、プレゼンテーションモデルの話もあるけど、それはまた別途。

*1:1段レイヤができるというだけで十分だから

*2:っていうのが個人的な見解ですが。