私はどのように私のビジネスロジック層を実装する必要がありますか？

Question

私は80％の複雑なビジネスロジックと20％のCRUD、またはその逆のアプリケーションを持っているとしましょう。

過去には、私は、コマンドパターンのいくつかの種類を使用し、ComplexFooCMDまたはEvenMoreComplexBarCMDのようなクラスを持っていたが、常にInsertFoo、UpdateFoo、DeleteFooとSelectFoosCMDの束とUpdateSomeValuesOfFooまたはSelectSomeFoosの数になってしまっています。これらのすべてはBLLに住んでいました。

は最近あまり複雑なビジネスロジックをアプリケーションに私は FooServiceのようなクラスを使用したサービスパターンを使用しているが、これらも期待 insertFoo、 updateFooと selectSomeFooが含まれています。これらのメソッドをすべてのサービスに置いたり、プレゼンテーションレイヤーにそれらのメソッドを公開するためだけに存在するサービスを持つことさえあれば、多くのボイラープレートコードのように感じます。

CRUDパートと他のアプリケーションの両方に適合するパターンがありますか、またはアプリケーションのさまざまな部分に異なるパターンを使用すべきですか？

Answer 1

CRUDをビジネスルールとは考えません。

「優良顧客に、年間売上高の関数であるパー​​センテージ割引を与える」または「クライアントのユーザーインターフェイスでこのオプションを表示しない」のようなルールのパターンがあるかどうかはわかりませんその会社の住所はこの州のリストからのものです」。

ビジネスルールは必ずしもきれいではありません。

Answer 2

behavior-driven developmentを読むことを強くお勧めします。私はそれが正しい方向にあなたを導くだろうと思う。

私がこのテーマで読んだベストブックはですが、Ruby中心の例がたくさんあるので、あなたが好きな言語に基づいて他のリソースを見たいと思うかもしれません。

簡単に言えば、あなたのテストはあなたのアーキテクチャをガイドして、あなたのアプリケーションの必要な振る舞いがテストの指針となるようにします。