ソフトウェアアプリケーションの異なる部分をきれいに分離する方法は？

多くのビジネスロジックを処理する新しいアプリケーションを設計しています。

時間の経過とともにこのようなシステムに潜入することが多い、さまざまなアプリケーションレイヤー間の通常の絡み合いを回避するために、最初から問題の明確な分離を実装したいと思います。大まかに言えば、私は分離したいです：

• プレゼンテーション層
• ビジネスロジックレイヤー
• データストレージと永続化レイヤー

私が最も苦労しているのは、特にビジネス層とデータ層の間で、実際にエッジで動作をきれいに実装する方法です。データレイヤーがORMオブジェクトをコアレイヤーに渡し、ビジネスロジックをORMに効果的に密結合するアプリケーションが多すぎます。

ORMオブジェクトをシリアル化された形式（JSON？）に変換してから、ビジネスレイヤーでそれを非シリアル化して、そのレイヤー内部のデータ構造にする必要がありますか？それは多くのオーバーヘッドではありませんか？

中規模アプリケーションの懸念の分離をきれいに実装するにはどうすればよいですか？何かアドバイス？

ビジネスロジックとデータベースの間には、常に何らかの論理的な結合があります。あなたの努力は、物理的な結合を防ぐことに焦点を当てるべきです。

たとえば、各ユーザーが一意のユーザーIDを持っている必要があるという非常に基本的なビジネスルールを考えてみます。ビジネスレイヤーでそのルールを適用することもできますが、複数のユーザーが同時に同じユーザーIDを試す可能性があるシナリオや、一意性を確認してユーザーIDを予約できる唯一の場所があります。アトミックな方法はデータベースにあります。

これで、ビジネスレイヤーはテーブルまたは列の名前を知っている必要はありません。また、ユーザーがデータベースに格納されている必要もありません（たとえば、イントラネットアプリケーションの場合は、代わりにActive Directoryに格納できます）。データアクセス層だけがそれを知っている必要があります。しかし、スキーマをビジネスルールから切り離すために多大な労力を費やすことは、おそらく無駄な努力です。

ビジネスモデルオブジェクトが、ORMまたはデータベースクライアントを参照しない独自のライブラリにあることを確認してください。

リポジトリパターンを使用し、メインコード内のリポジトリへの参照インターフェースのみを使用します。

インターフェースライブラリ、ビジネスモデルライブラリ、およびデータベースクライアントを参照する、データレイヤー固有の完全に別個の具体的なリポジトリライブラリを用意します。