現在、コア ビジネス コンポーネント (コード内) をフロント エンド開発から分離する方法を検討しています。多層アーキテクチャは既にありますが、それらは dll (または一部の場所では Web サービス) を使用して参照されます。
私たちがやりたいことは、UI の一部を外部の開発者に委託することです。問題は、リバース エンジニアリング可能な dll を提供する必要があり、コア ビジネス ロジック コードを「取得」できることです。
dll を使用して BO を公開する代わりに、これに取り組む 1 つの方法は、Web サービスを使用して BO を公開することです。ただし、問題はほとんどありません。たとえば、セキュリティ、デバッグ、例外処理、ホスティングなどです。私には、これは上記の問題に対して適切ではないように思えますが、Web サービスもそのような問題には適していません。
誰かが同様のシナリオに出くわしたのだろうか？または誰かがこれをした場合は？もしそうならどのように？
ありがとう、
ビジネス ロジックを実装する Web サービス ポイントを提供します。これは自分でホストし、UI 開発者がアクセスできます。
このようにして、ビジネス ロジックを制御し続け、UI チームは API にアクセスできます。
これが不可能な場合は、ビジネス ロジックのパブリック インターフェイスを独自のパッケージに抽出し、一連の「定型化された」応答を実装します。これは、UI 担当者が操作するデータをハード コーディングしただけです。これにより、UI チームが統合するインターフェイスとサンプル データを提供できますが、実際のビジネス ロジックは必要ありません。
ここでは、インターフェイス コントラクトの概念が適切に見えます。
インターフェイスのコントラクトが明確に定義されている場合 (DLL エントリ ポイントや WSDL など)、UI 開発者が動作をテストできるようにするモック実装を作成することはそれほど難しくありません。
私たちがとった唯一の予防策は、UI 請負業者に SVN リポジトリにコードをコミットするよう依頼することです (いいえ、Git はありません :))。これにより、ビルド マシンが継続的に統合テストを実行し、進行状況と問題を毎日評価できるようになります。
Y 原則は、求めている関心事の分離を実現するのに役立つ場合があります。
これは、ビジネス上の問題と技術的な問題を体系的に分離するための方法です。
次のキャラクター グラフィックは、アプローチを示しています。
Business requirements Technical requirements
+------ | | ------+
| v v |
| Business model Technical model |
\ \ / /
\ \ / /
\ \ / /
\ > Mapping rules < /
\ | /
\ | /
\ v /
\ Implementation /
\ | /
\ | /
\ v /
Acceptance Tests
マッピング ルールに一貫性があり、繰り返し適用できる場合は、このアプローチを自動化できます。逆 y 分析は、これが当てはまるかどうかを示すことができます。
このアプローチが適用できる場合、効率に大きな影響を与えるでしょう。ビジネス上の問題を技術的な問題に何度もマッピングする代わりに、プロセスを反復可能にし、最終的には自動化することができます。
詳細については、私の会社の Web ページを参照してください。