私が構築しているソフトウェアの中心的な信条は、「作業順序」です。
WorkOrder は、作成日、モデル/製造元、シリアル番号、注文書などの作業指示書に関する基本情報を含む「集約ルート」になります。
これらの「値」オブジェクトに加えて、次のようなサブ「エンティティ」または「集合体」もあります。
- シーケンス
- リワーク
- 寸法
- 見積もり項目
- 消耗品
上記のいずれも、関連付けられた作業指示書なしでは存在できません/存在すべきではありません。既存のシステムでは実際に時折そうしますが、それは整合性を確保するためのトランザクションまたはコードのチェックが不足しているためです。それらは孤立したレコードであり、スケジュールされたクリーンアップによって削除されます。これが、開発プラクティスをスピードアップするために DDD と ORM についてさらに学習している多くの理由の 1 つです。
注: これはおそらくトピックから外れているため、返信でスキップされる可能性があります
私たちは主に extJS を使用した Web ベースのインターフェイスであり、上記の各項目を表示する各リスト コントロールであるため、ORM と DDD に切り替えることには消極的でした。各リストは、DB を照会する controller:action を介して入力されます (つまり、JS コントロールが GET コマンドでシーケンス REST URI を呼び出すと、シーケンス リストが入力されます)。この GET コマンドは、シーケンス オブジェクトをインスタンス化し、 selectAllForWorkorderIDメソッドを呼び出すコントローラーを呼び出します。
ORM についての私の理解では、リポジトリを使用してこれらのアイテムをクエリします。ただし、このシーケンス オブジェクト (DDD の用語で) が WorkOrder ルートの集合体と見なされる場合は、最初に WorkOrder を見つけて、WorkOrder を介してシーケンスをトラバースする必要があります。
AJAX Web ベースのコンテキストでは、これはおかしいと思いますが、デスクトップ環境や標準の Web ベースのコンテキストでさえ、マスター リストで WorkOrder 項目が選択されるたびに WorkOrder オブジェクトを 1 回だけクエリするだけなので、これは許容されます。個々のリストに入力するのに 6 回または 8 回ではありません。
私たちのシステムには実際にいくつかの集約ルート オブジェクトがあることがわかりました。
- 作業命令
- 保証
- 修理依頼
主根です。保証は作業指示書 ID に依存しており、修理指示書は常にそうであるとは限りません。
後者のルーツを無視して、WorkOrder だけに集中させてください。
既存のモデルを調べて、ビジネス ロジックやアプリケーション ロジックとは何かを判断しようとすると、少し混乱します。「サービス」と「集約ルート」の違い。
現在のモデルでそのような方法の 1 つを検討してください。
createWorkOrderFromRpi.
RPI は、WorkOrders のテンプレートとして機能する承認されたドキュメントです。RPI は、実行できるシーケンスと実行順序、寸法、消耗品のリストなどを指示します。これは完全に別のシステムであり、「モジュール" DDD命名法で。
このメソッドは、RPI システムにクエリを実行し、作業指示ヘッダーの詳細、シーケンス リスト、消耗品などを取得する必要があります。
このデータを取得すると、関連するオブジェクトとメソッドが呼び出されます。
- WorkOrder.Create(ヘッダーの詳細)
- Sequence.Create(Sequence Details) - ループで実行 (1:m)
- Consumable.Create(Consumable Details) - ループで実行 (1:m)
次の DDD では、WorkOrder の「集約ルート」に同一の署名を持つメソッドを提供させたいと思いますが、そうするのは気が進まないのです。
WorkOrder の集合体である「エンティティ」のそれぞれは、説明に適合し、ルート自体を通過しない限り、「ルート」の外部にさらされるべきではないと私は信じています。そうでない場合もあるかもしれません。よく考えてみると、インターフェースは消耗品やシーケンスなどを公開するだけで、作業指示書が選択されている場合、とにかく作業指示書をロードする必要があることを暗示しています?!?
このメソッドが実行する必要がある重要なビジネス ルールがいくつかあります。
- 同一のシリアル番号を持つ作業指示書は、(アーカイブされていない限り) システムにアクティブにはまだ存在していません (アーカイブされていない限り)。
他にもいくつか「ルール」がありますが、簡潔にするために除外します。
個々のエンティティは、マイクロ ビジネスの検証を実行します。たとえば、シリアル番号などの一部のフィールドには、部品番号や注文番号と同様に特定の形式があります。
私の主な質問または懸念事項は、上記の説明が与えられていることですが、このメソッドは「集約ルート」または「サービス」で実装するのが最適でしょうか?
更新 | 最後の質問...集約ルートが適切な概念である場合...そして、概念的にアクセスするフィールドを更新できるように、シーケンスにアクセスする必要があります(構文を無視します):
WorkOrder.Sequences(0).moveToNext()
このメソッドがシーケンス「エンティティ」に実装されている場合、それは理にかなっています。技術的な詳細とビジネス ロジックの境界はどこにありますか? たとえば、あるシーケンスから次のシーケンスに作業指示を移動するには、シーケンスごとに 3 つのタイムスタンプを更新します。
date_entered date_started date_finished
最後のタイムスタンプが設定されると、次のシーケンス date_entered が前のシーケンス date_finished と同じ時刻に設定され、システムはこれが現在アクティブなシーケンスであることを認識します。それは技術的な問題です。
ただし、ビジネス ルールまたは制約は次のようになります。
- 履歴に移動された場合、作業指示書を移動しないでください
- やり直し中の場合は作業指示を移動しないでください
- サブコンの場合は作業指示書を移動しないでください
これらは規則であり、管理を生きた文書および機能の証明として提示できる仕様文書の形で簡単に英語に翻訳できるように、分離して区別しておきたいと考えています。私は、それが DDD がクリーンな方法で実施/促進するものであることを望んでいました。これは DDD とは別に処理される要件ですか? これがCQSの出番ですか？利害関係者に関係のない技術的な問題からビジネス ルールを分離しますか?
アレックス