2

私のアプリケーションでは、生産ラインのステーション間を移動する製品があります。ステーションで製品が通過するたびに結果が記録されます: 成功または失敗。製品とステーションの関係は多対多です。

手続き型言語でプログラミングしているとしたら、次の関数があります。

get_last_pass_result($station_id, $product_id) {...}

これは、この特定の製品がこの特定のステーションを最後に通過したときの結果を返します。

このロジックを OOP 用語でどのようにモデル化しますか? 私は間違いなくクラスステーションとクラス製品を持っているでしょう. しかし、私はすべきですか（php構文）：

$station->get_last_product_pass_result($product_id)

または

$product->get_last_pass_on_station_result($station_id)

状況は対称的に見えますが、どのような考慮事項が 2 つの間で決定されるのでしょうか (または、3 番目の解決策でさえありますか?)

ドメインに関するすべての既存の情報をここで提供することはできませんが、次のような考慮事項を自由に含めてください。

4

4 に答える 4

3

私の考えですが、DDDの原則に基づいているので、これがあなたのニーズに合っているかどうかはわかりませんが、とにかく...

つまり、ステーションと製品があります。これらは両方とも相互に参照できるエンティティであると言えますが、あなたが話しているロジックはこれらのエンティティを包含しており、 GetLastPassFor（product、station）のような操作でProductPassingServiceのようなドメインサービスに入れることができます。

このドメインサービスは、基盤となるドメインエンティティであるStationとProduct（およびそれらをクエリするためのリポジトリ）を使用し、StationとProductのどちらにも属さないロジックを実行する責任があります。これにより、ステーションと製品のエンティティに過度の責任がなくなります。

また、ドメインエンティティはリポジトリ（DDD-エンティティがリポジトリに直接アクセスできないというルール）を使用しないようにする必要があるため、このロジックはドメインサービスに属します。

于 2013-03-14T08:03:02.763 に答える
1

Productが製品のタイプ (椅子など) を表しているのか、製品の個々のインスタンス (chair-001、chair-002 など) を表しているのかは完全にはわかりません。あなたの例から、後者のように見えるので、それを使用します。そうでなければ、get_last_pass_resultあまり意味がありません。

私はタイプを導入すると信じてPathいます (ただし、ドメインについてよく知らなくても)。現在、他の使用例に応じて、これは (DDD 用語で) 集約ルートである場合とそうでない場合があります。

これは、Productインスタンスを介して、または DB/リポジトリなどから直接アクセスできることを意味します。パス インスタンスを使用すると、次のように簡単に実行できます。

var path = product.GetPath(); // if it is accessible only via product
var path = Path.GetPathForProduct(product); // or pathRepository.GetPathFor(), or ...
var result = path.LastResult;

このアプローチは、工場のプロセスを製品自体から分離し、他のいくつかのシナリオを可能にします (例: 平均期間を見つけるなど...)。

于 2013-03-14T08:53:52.960 に答える
1

いつものように、使い方次第です。

しかし、ディスカバリー チャンネル (自動車工場) には、「どのように機能するか」という優れたサンプルがあります。コンベアを通過する過程で、自動車はますます多くの追加部品を受け取ります。各自動車には、タスクを完了するために実行するジョブのリストである、一種のジョブ スケジュールが添付されています。ラインを通過する間、作業担当者が作業完了の印を付けます。したがって、欠陥が見つかった場合、その原因は確実にわかります。

それでは、手続き型アプローチに戻ります。まず、純粋な oop の代わりに構造 + 手順のアプローチを使用する方が自然です。もちろん、それはあなた次第です。

2 つ目は、製品と 1 対 1 の関係にある「生産ライン ログ」オブジェクトから「製品」を分離することをお勧めしますが、製品がリリースされた後はおそらく必要ありません。「生産ラインログ」には、ステーションごとのオブジェクト処理に関するイベントが保存されます。さらに、スケジュールとして使用することもできます。つまり、特定の製品をどのように処理するかの指示を含めることができます (自動車にコンディショナーやフォグランプなどの特定の機能を含めるかどうかなど)。また、「計画された」アクションは、ワーカーによって「完了」としてマークされる必要があります。

今日では、「イベント ソーシング」という用語でも表現できます。移動中、製品の変更はログに書き込まれます。そのため、変更イベントを 1 つずつ再生することで製品を再構築できます。

于 2013-03-14T20:35:09.277 に答える
0

製品に入れることをお勧めします。商品数が多いのではないかと思いますが、ステーションを固定する必要があり、その商品の対象に特定の商品の状態を記録するのは当然です。ステーションの場合、一部の統計を記録するだけでよい場合があります。

于 2013-03-14T06:42:19.480 に答える