これまでで重量SOAについて理解していただけたと思う。重量といえども従来に比べればかなり軽量ではある。これはあくまでも多くの人がWebアプリケーションを開発することを意識したので重量になってしまった。しかし、S2の真髄は軽量である。当然、軽量な開発方法がある。残念ながらすべてを網羅できないが、あるケースについては有益である。これは「画面群が１ユースケース」という比嘉氏の提案に素直に納得できなかったことの裏返しである。あるケースとは、従来から述べてきたマスタメンテナンス系のサービスである。そして、あらゆるシステムはマスタメンテナンスであるという私の主張でいけば、軽量的に開発できることになる。
これは、UI仕様書（Validationつき）とエンティティ仕様書とを明示的に関連づけてしまい（一枚にできないか）、バウンダリからサービスを経由しないで（デザイン的にはスルーして）S2Daoをたたくことで実現できる(Excelでうんぬんを突き詰めたい)。
こうなると次に何を述べるかは自明であろう。前述はルール（業務ロジック）がなかったが、ルールがある場合はコンポーネント仕様書が示すコンポーネント名をUI仕様書（Validationつき）とエンティティ仕様書の間で入れる。これについてマスタメンテナンス系が整理されたら再度述べたい。コンポーネント仕様書をハリセンがパースしてくれるとよいということだ。
これこれ
UI仕様（細かく書く） ER図 ロジック仕様補足資料（ロバストネス図に書き込み可） くらいですよね。いいんじゃないでしょうか。UI仕様をExcelで書いて、項目部分をそのままS2Dao使ってスキーマ生成ってすると、それをERDツールでまとめてリバースすればER分析の手間も大幅に減りますね。いえ、昨日S2Daoの話を1度もしなかったのでついつい書いてみただけです（ｗ んで、新業務フローを書くための話っていうのは、要求分析フェーズということで別出ししておくということで。こちらも手順はまとめます。 追記：画面とエンティティの項目マッピングって、いわゆるトランスファルールってやつですけど、コントローラがこれだけならExcelから自動生成しちゃってもいいんだよな
そうそう。いいんです。ロジックがあってもいけるんです。
コンポーネント仕様書という名称でよいのか、サービス仕様書ではないのかという疑問がわいてきた。
