エンタープライズアーキテクチャ パターンのドメインロジック

必要があって、エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)の次の章を読み返しました。

第２章 ドメインロジックの構築
第９章 ドメインロジックパターン

第２章では３つのパターンを用いて業務ロジックを記述した場合の説明とそれぞれの使い分けが記述されています。SOAではこのうちのドメインモデルの方式を全体でやりましょう、ということだと理解しています。
（どこまでを全体として定義するかがポイントだと思いますが。全体の対象が１アプリケーションならプロジェクトの中のライブラリレベルの再利用活動になってしまいます、それも大事だけど。）

テーブルモジュールという方式をあまり理解できていないのですが、最近はデーブルドリブンの開発も盛んに行われており、それに当たるのでしょうか（Ruby on Railsとか）？
個人的には企業システムにおけるUIは短期間、低コストで作成して、ユーザの要求、業務の変化に応じてスクラップ＆ビルドがいいのでは、と考えているので、UIはツール／フレームワークに任せてサービス定義（WSDL）やテーブル定義から自動生成が適していると考えています。ただ、日本の企業では現場のユーザが強いので、この考え方はあまり受け入れられないかも知れません。どうしてもリッチなUIになりがち。

また２章ではドメインモデルを採用するに当たって、サービス層とドメインモデル層に分厚さの関係を３案定義しています。どのような機能をどちらの層に配置すべきかという議論です。

第９章に関してはサービス境界の定義がやはり難しいというか、こうやれば自ずと決まるというものではない。本書でもその分割手法自体には触れられていません。昨日注文した実践UML 第3版 オブジェクト指向分析設計と反復型開発入門にヒントがあればいいな！

また、もう一つのテーマとしては第２章とも重なりますが、どの機能をドメインモデルに配置すべきかという問題があります。
つまり、縦の層への機能配置と、横のサービス境界（サブシステム分割と考えても良い）がポイントとなりそうです。

いつも思うのですがパターンだとかフレームというのは、考え方の整理であって自分の考えにヌケが無いか、偏りがないかを確認するためのものだと思います。ですから、分析した結果の考察や今後どうするかは自分の頭で考えるしかないんですよね。