つまり、業務フローと業務ロジックにかかわる部分だけに慎重に考えている。
極言するとアクションサーブレット(struts-config.xml)が業務フローで、アクションクラス（から先）が業務ロジックと考えれば、コントロール層でなくてルールエンジンの問題としてよいければ、コントロール層は確かにいらない。問題は、アクションサーブレット、アクションクラスとStruts語を使うと反射的にMVC、コントロールと思ってしまうわけで、このあたりの思考のギャップを埋めておきたい。というかなんとなくもやもやしている。ダイコン時代の設計手法についてもおおむね合意なんですが（なんかえらそうですみません）、詳細は議論しておきたいです。UML+ERというところは同じでもその前にロバストネスするかしないかで敷居がかわってくると思う。また、「サービスをステートレスに」も具体的にはいまのところFDDしか思いつかないが他には方法はないのか。そもそも「サービス」というあいまいな言葉を使って切り出せるのか（これについて後日）。これはプロセスだから勝手にすればという意見もありだが、もやもやしている。というか気持ちはルールエディタに飛んでいるせいだと思う。はぶさんに会う前にプロセスについてはまとめたいと思っているのだが・・・・とりあえず、タイトルは「プロセス定義は悪」まで書きました。(^^;
ちょっとひがさんと同期がとれてきた。ひがさんの考えをいれて改訂したい。
