Dan氏によると以下のとおりである。
アーキテクチャー(および開発の大部分)は、決まった規則、cookieカッタースタイルで実行され、パターンおよびテクノロジーのカタログを取得し、それらを適用して、作業が完了する、と信じたい。こうした流れは最終的には、 ESBをデプロイすることで、システムをSOAにすることができる。
すばらしいアーキテクチャデータでさえも、データの依存関係は避けられないし、コードやデータを垂直にレイヤリングして、サービス「ユニット」をデータで 直接依存関係を結ばれることから、チェーンの上位で分離することを提案している。このレイヤリング形式には独特の欠点がある。なぜならば、ロケーションに とらわれないことと、上位サービスユニットへの同期呼び出しを前提としているからである。こうした前提に関する問題を避けるために、「対話のために依存が 使用するネットワークエンドポイント経由でアクセスされる、独自のプロセス内で各ユニットをデプロイする」ことを提案している。そのようなデプロイメント は、sharding、平行スケーリングおよびロードバランシングのようなテクニックを使用することでランタイムパフォーマンスに利点をもたらし、またこ れらのユニットをテストしたり、ホットパッチするという観点からみると保守容易性にも利点をもたらす。また、チームが「他の開発作業とは単独に作業をする ので、開発過程で衝突が少なくなる」。
コードやデータをレイヤリングしたり、分散アーキテクチャを選択したり、設計の選択に関する整合性の問題について考えるべき注記や、「分散コンピューティングについての誤った考え(source)を考慮」することをまとめた一連のガイドラインを提案している。
- 整合性、可用性および分断(CAP)(source)要求の類似点の検討
- データアクセスローカリティ
- データ関係
- 管轄要求
- 役割および責務(OOより粗いレベル)
- 機能(たとえば、推奨)
- ビジネスプロセス
- ビジネスプロセス全体の構成要素
... そして最後に「たいていのシステムは、大いに価値がある1つの決まったアプローチやテイストや本能的直感(source)ではなく、こうしたガイドラインの組み合わせを要求する傾向にある」と述べて結んでいる。併せて元の投稿記事(source)も参照したい。