language-agnostic - ビジネスオブジェクト-コンテナまたは機能？

Question

私が働いている場所では、このテーマについて何度も行ったり来たりして、健全性チェックを探しています。質問は次のとおりです。ビジネスオブジェクトはデータコンテナ（DTOのようなもの）である必要がありますか、それともそのオブジェクトでいくつかの機能を実行できるロジックも含まれている必要があります。

例-顧客オブジェクトを取り上げます。おそらくいくつかの一般的なプロパティ（名前、IDなど）が含まれていますが、その顧客オブジェクトには関数（保存、計算など）も含める必要がありますか？

1行の推論では、オブジェクトを機能（単一責任プリンシパル）から分離し、機能をビジネスロジックレイヤーまたはオブジェクトに配置します。

もう1つの理由は、いいえ、顧客オブジェクトがある場合は、Customer.Saveを呼び出して、それで完了します。オブジェクトを消費している場合、なぜ顧客を救う方法を知る必要があるのですか？

最後の2つのプロジェクトでは、オブジェクトが機能から分離されていましたが、新しいプロジェクトについて再び議論が行われています。どちらがより理にかなっていますか？

編集

これらの結果は、私たちの議論と非常によく似ています。どちらか一方に投票すると、方向が完全に変わります。他の誰かが彼らの2セントを追加したいですか？

編集

回答のサンプリングは少ないですが、ビジネスオブジェクトの機能は単純である限り許容できると大多数が信じているようですが、永続性は別のクラス/レイヤーに配置するのが最適です。これを試してみます。皆様のご意見ありがとうございました...

score 10 · Accepted Answer

オブジェクトは、状態と動作を一緒にしたものです。オブジェクトに賢明な振る舞いがある場合（たとえば、誕生日から人の年齢を計算したり、請求書の合計税額を計算したりする場合）、必ずそれを追加してください。DTOにすぎないビジネスオブジェクトは、「貧血ドメインモデル」と呼ばれます。設計要件ではないと思います。

永続性は特別な種類の動作です。私が「賢明」と呼んでいるのはビジネス行動です。ビジネスオブジェクトは、それが永続的であることを知る必要はありません。DAOは、永続性をビジネスの振る舞いとは別に保つことができると思います。私は「保存」を「賢明な」カテゴリに入れません。

score 9 · Accepted Answer

ビジネスオブジェクトはビジネス機能を持つことができます。

永続性はビジネス機能ではありませんが、技術的な実装です。

短編小説：

保存/更新/削除/検索など-永続層のビジネスオブジェクトから遠ざけます。
CalculateSalary、ApplyDiscountなどはビジネス関連のメソッドであり、次のようになります。
1. ビジネスオブジェクトのメソッド（つまり、 BOはエンティティの自己完結型表現です）または;
2. 特定の機能を実装する個別のサービス（したがって、BOはDTOのように機能します）。

ポイント2
については、2.1のアプローチでは、BOが肥大化しすぎて、SRPに違反する傾向があることに注意してください。2.2ではメンテナンスがさらに複雑になります。

私は通常2.1と2.2のバランスを取り、データに関連する些細なことをBusiness Objectsに入れて、もう少し複雑なシナリオのサービスを作成します（4行を超えるコードがある場合はサービスにします）。

これにより、ビジネスオブジェクトのパラダイムがより多くのデータ転送オブジェクトにシフトします。

しかし、これにより、プロジェクトの開発、テスト、および保守が容易になります。

score 4 · Accepted Answer

答えは、プラットフォームや言語に関係なく同じです。この質問の鍵は、オブジェクトが自律可能である必要があるかどうか、または特定の動作がより焦点を絞った責任を持つオブジェクト間で分散される方がよいかどうかです。

クラスごとに答えが異なる場合があります。最終的には、責任の密度に基づいてクラスを配置できるスペクトルになります。

                          (Level of responsibility for behavior)
         Autonomy - - - - - - - - - - - - - - - - - - - Dependence  
      High
  C      -   <<GOD object>>                            <<Spaghetti code>>
  l      -
  a      -  
  s      -                                      
  s      -                 
         -                        
  s      -  
  i      -  
  z      -
  e      -  <<Template>>                                <<Framework>>
       low

クラスにすべての動作自体、またはできるだけ多くの動作を実行させることを好むとしましょう。このグラフの左側から始めて、クラスをより自律的にすると、クラスをより一般的にするために継続的にリファクタリングしない限り、クラスのサイズが大きくなります。これにより、テンプレートが作成されます。リファクタリングが行われない場合、クラスがより「神のよう」になる傾向があります。必要な動作がある場合は、そのためのメソッドがあるためです。フィールドとメソッドの数は増え、すぐに管理不能と不可避の両方になります。クラスはすでに多くのことを行っているので、コーダーはそれをバラバラにしてゴーディアンノットを切るよりもむしろ怪物に追加したいと思います。

グラフの右側には、他のクラスに大きく依存するクラスがあります。依存関係レベルは高いが個々のクラスが小さい場合、それはフレームワークの兆候です。各クラスはあまり機能せず、いくつかの機能を実行するには多くの依存クラスが必要です。一方、コード量も多い依存度の高いクラスは、クラスがスパゲッティでいっぱいであることを示しています。

この質問の鍵は、グラフのどこがより快適であるかを判断することです。いずれにせよ、何らかの組織的原則が適用されない限り、個々のクラスはグラフ上に広がることになります。これにより、テンプレートまたはフレームワークの結果を達成できます。

それを書いたばかりですが、クラスの規模と組織の程度には相関関係があると言えます。Robert C. Martin（または「UncleBob」）は、設計原則と設計パターンに関する彼の非常に徹底的な論文で、パッケージの依存関係について同様の根拠を取り上げています。 JDependは、26ページのグラフの背後にあるアイデアの実装であり、CheckstyleやPMDなどの静的分析ツールを補完します。

score 2 · Accepted Answer

ビジネスオブジェクトが自分自身を「処理」する方法を知ってから、その負担をシステムの他の場所に置く必要がある方が理にかなっていると思います。あなたの例では、顧客データを「保存」する方法を扱う最も論理的な場所は、私にとって、Customerオブジェクトです。

これは、データベースを「データコンテナ」と見なしているためか、データコンテナを直接アクセスから保護し、そのデータの方法に関する標準の「ビジネスルール」を適用する上位レベルの「ビジネスオブジェクト」を支持しています。アクセス/操作されます。

score 2 · Accepted Answer

Rocky LhotkaのCSLAフレームワークを何年も使用しており、その設計方法が気に入っています。そのフレームワークでは、すべての機能がオブジェクトに含まれています。ロジックを分離することの価値はわかりますが、すぐにこの哲学から離れることはないと思います。

score 1 · Accepted Answer

ビジネスオブジェクトは、そのオブジェクトによってモデル化されたビジネスエンティティのデータと関連する動作をカプセル化することに関するものでなければなりません。このように考えてください。オブジェクト指向プログラミングの主要な信条の1つは、データとそのデータに関連する動作をカプセル化することです。

永続性は、モデル化されたオブジェクトの動作ではありません。ビジネスオブジェクトが永続性を無視している場合、開発はよりスムーズに進行します。新しいコードの開発と新しいコードの単体テストは、ビジネスオブジェクトが基礎となる配管に特に関連付けられていない場合、より迅速かつスムーズに行われます。これは、これらの側面をモックして、データベースにアクセスするためにフープを実行する必要がないことなどを忘れることができるためです。ユニットテストはより迅速に実行されます（ビルドごとに何千もの自動テストを実行する場合は大きなプラスになります）。データベース接続の問題が原因でテストが失敗することがないため、ストレスが少なくなります（オフラインまたはリモートで作業することが多く、常にデータベースにアクセスできない場合に最適です。ちなみに、これらの側面（データベース接続など）は他の場所でテストしてください！）。

Customer.Saveもう1つの理由は、いいえ、顧客オブジェクトがある場合は、電話してそれで済ませたいというものです。オブジェクトを消費している場合、なぜ顧客を救う方法を知る必要があるのですか？

Customerそれがメソッドを持っていることを知っていることはSave、顧客オブジェクトを保存する方法をすでに知っています。そのロジックをビジネスオブジェクトに埋め込むことで問題を回避していません。代わりに、コードベースをより緊密に結合しているため、保守とテストが困難になっています。オブジェクトを他の誰かに永続化する責任を押しのけてください。

score 0 · Accepted Answer

ビジネスオブジェクトは、その名前が付けられているように、明らかに独自のビジネスロジックを備えている必要があり、ドメイン間のビジネスロジックのダイナミクスはサービスレイヤーにあります。

一方、BOはデータコンテナ（DTO？）の構成とメソッドである可能性があります。BOが純粋に機能的であることを意味しますか？これにより、BOとDTO間のすべての変換を回避できます。

score -1 · Accepted Answer

MVCアーキテクチャでは、

Modelにはビジネスオブジェクトが含まれていると言えますか。

language-agnostic - ビジネスオブジェクト-コンテナまたは機能？

8 に答える 8

Related

Reference