ソフトウェアアプリケーションの異なる部分をきれいに分離する方法は？
多くのビジネスロジックを処理する新しいアプリケーションを設計しています。
時間の経過とともにこのようなシステムに潜入することが多い、さまざまなアプリケーションレイヤー間の通常の絡み合いを回避するために、最初から懸念事項を明確に分離したいと考えています。大まかに言えば、私は分離したいです：
- プレゼンテーション層
- ビジネスロジックレイヤー
- データストレージと永続化レイヤー
私が最も苦労している質問は、特にビジネス層とデータ層の間で、エッジで動作を実際にきれいに実装する方法です。データレイヤーがORMオブジェクトをコアレイヤーに渡し、ビジネスロジックをORMに効果的に密結合するアプリケーションが多すぎます。
ORMオブジェクトをシリアル化された形式（JSON？）に変換してから、ビジネスレイヤーでそれを非シリアル化して、そのレイヤーの内部のデータ構造にする必要がありますか？それは多くのオーバーヘッドではありませんか？
中規模アプリケーションの懸念の分離をどのようにして明確に実装しますか？何かアドバイス？
ビジネスロジックとデータベースの間には、常にlogicalの結合が存在します。あなたの努力は物理的カップリングを防ぐことに焦点を当てるべきです。
たとえば、各ユーザーには一意のユーザーIDが必要であるという非常に基本的なビジネスルールを考えてみます。ビジネスレイヤーでそのルールを適用することもできますが、複数のユーザーが同時に同じユーザーIDを試す可能性があるシナリオや、一意性を確認してユーザーIDを予約できる唯一の場所があります。アトミックな方法はデータベースにあります。
これで、ビジネスレイヤーは、テーブルまたは列の名前を知っている必要はなく、ユーザーがデータベースに格納されている必要もありません（たとえば、イントラネットアプリケーションの場合は、代わりにActive Directoryに格納できます）。データアクセス層だけがそれを知っている必要があります。しかし、スキーマをビジネスルールから切り離すために多大な労力を費やすことは、おそらく無駄な努力です。
ビジネスモデルオブジェクトが、ORMまたはデータベースクライアントを参照しない独自のライブラリにあることを確認してください。
リポジトリパターンを使用し、メインコードでリポジトリへの参照インターフェースのみを使用します。
インターフェースライブラリ、ビジネスモデルライブラリ、データベースクライアントを参照する、データレイヤーに固有の完全に別個の具体的なリポジトリライブラリを用意します。