設計＠走り書き

Webでの設計で、サービスとか良く判らない層を定義してたりする
設計って在るけれども

それって、うれしいの？
あくまでも、アクションがサービスとの
界面になってしまってアクションの債務は？

それだとアクションいらなくね？

アクションに、重複する物を、アプリケーションの中で
子アプリケーションとしてサービスとして切り出すって事にしても
どうやって重複を切り出すの？
リファクタリング？

そもそも、なぜアクションが必要か？

ユーザーが起こすアクションをプロセスに繋げて
何かしらのリソースを返す際の発火点が必要だからだろう

そして、その発火点で在るアクションを設計するって事は
ユーザー側、インタフェースの設計だ。其処に内部の処理は関係ない

また、アクションが返すリソース側
これは、内部の処理で在って、サービスだ

だから、サービスとアクションにインピーダンスミスマッチが発生する
だから、サービスの切り出しが難しいだ。

ActionとView、ユーザーに一番近い側
そして、Logic、ユーザーに一番遠い側

でも、ロジックってのは所詮
ユーザーに提供するデータを扱う物で在ってリソースを処理する為の物だ
それは、アプリケーションとしての主軸だ。

だから
リソースなりロジック也を定義して

それにユーザーとのインタフェースで在るアクションを付ける

それで、Webアプリケーションが出来る

ただし

そのリソースを定義する際に
ユーザーのインタフェースを元にして
こういったリソースが必要で在るって事を
探る事も在る

両者の設計のインピーダンスミスマッチ
ココを、上手く捌ききる手法が確立すれば

サービスだとか、アクションだとか
そういった設計に悩まなくて済む

でも、設計ってのは、うんうん悩む物だから
永遠に悩むべき物でも在ると思う

だから、判らない時の手助け
もしくは、綺麗にする為の体系的な物
デザインパターン的な物が
その部分に発生してくれると嬉しいのだろうな