下記は一般的なn層アーキテクチャーの図です。各層をここでは「Presentation」、「Business Logic」、「Data Access」と表現しています。
ただしいくつか特徴があります。一点目は、参照系と更新系のBusiness Logicを分別して表現していること。二点目は、「Access Control」機能を明示し、かつ、参照系では「Operation」と明確に分離させていて、更新系では境界を曖昧としています。
更新系Business Logicに対して「Lifecycle Management Operations」と別名を与えています。ここで「参照系」「更新系」の用語を、低レベルI/Oとしての単純CRUDを意味するものとしては用いていません。業務データは、作成され、何段階かの更新（※一般に更新操作は複数種類ある）がなされ、最後に破棄されるという経緯を経るでしょう。業務のプロセスを永続化データの状態遷移と見たとき、プロセスのアクティビティは「状態遷移を引き起こすアクション」と捉えられます。更新系操作＝「業務の永続化データを如何に更新するか」とは、つまり「プロセスにおいて可能とするあるいは許可する状態遷移を次々と引き起こすようなアクション（群）」を意味すると理解します。以上のことを言い表すものとして「（業務データの）Lifecycle Management」という用語を用いました。
プロセスのアクティビティを定義するとき、アクセス制御のポリシーと明確に分離して定義する事は難しいと考えています。アクセス制御ポリシーを定義するときには、ロールを規定することとなります。プロセスのアクティビティは往々にして特定のロールの存在を想定します。結局、ロールに対する要件はプロセスを構成する特定のアクティビティから出る要件に影響を受けざるを得えません。よって、よりアクセス制御の色彩が強い機能要件と、よりアクセス制御の色彩が薄い機能要件とはあっても、両者を完全に分離して捉える事はできないと考えています。これは更新系の話です。
一方の参照系は、一般的に考えられる構成と同じです。業務データの上にアクセス制御の層が乗って、その上に「Query Operations」と称したBusiness Logic層を置いています。
参照系のBusiness Logicの機能要件の多くはデータ利用側から発せられます。「どのようにデータを見せたいか？」というより「どのようにデータを見たいか？」というかたちで現れます。否、「どのように見せたいか？」というかたちの要求も出てきますが、多くの場合それは「どのようには見せたくないか？（＝一定の条件を守る限りどのように見てもらっても構わない）」、即ち制約としてのアクセス制御に関する要件であることが実態だと解されます。更新系の要件が、データ提供側が自ら表現したい業務プロセス進行の各ステップそのものとしてデータ提供側から発せられるのとは対照的に、参照系の要件はデータの利用側から発せられます。
◇
さて、以上のように説明されるn層アーキテクチャー構成図に、フロントエンド（＝データ利用側）とバックエンド（＝データ提供側）の境界線を引いてみます。
まずはSOA的な考えにおけるI/Fです。
Business Logicがサービスとして提供されている様子が描かれます。
次にROA的な考えで捉えたI/Fです。
Business Logicというより比較的低レベルI/OとしてのCRUDが提供されます。アクセス制御はデータ提供側で装備されるでしょう。（※図中、線Aで表しています。）プライベートに運用されるシステムの場合は、アクセス制御の層もデータ利用側の責務として、よりDirectなCRUDを提供することもあります。（※図中、線Bで表しています。）
最後に、筆者が提案したいI/Fの取り方です。
参照系のBusiness Logicはデータ利用側発の要件に基づくだろうという理解から、参照系Business Logicそのものはデータ利用側の責務として、データ提供側としてはアクセス制御をかけただけの比較的低レベルの汎用I/O I/Fを提供します。即ち参照系はROA的な考えでI/Fを定めます。対照的に、更新系のBusiness Logicはデータ提供側が維持したい業務プロセスのアクティビティから発せられる要件に基づくだろうから、更新系Business Logicはデータ提供側の責務とします。即ち更新系はSOA的な考えでI/Fを定めます。
参照系Business Logicについて、データ提供側としては具体的なLogicを定めず、アクセス制御の制約の範囲で自由に参照させるという考えは、昨今の「オープンデータ」の考えにも通じるものと考えます。
◆以上
