データモデルの再利用レイヤー

再利用のデータモデルの設計は、ソフトウェアプロジェクトの中でも最も重要な分野に挙げられます。 優れた設計のデータモデルには相乗効果があり、全体は部分の総和に勝ります。 一方、データモデルの設計が不十分だと、アプリケーションの品質や保守性が損なわれます。

ケースタイプの作成後、すぐにそのライフサイクルを定義したい場合もあるでしょう。 App Studioでは、ケースレベルで定義された多数のプロパティを含むビューを使用して、ケースライフサイクルを迅速に開発できます。 しかし、この方法は逆効果です。他のケースと共有される再利用可能なデータクラスやワークプールレベルのプロパティがないため、 コードのリファクタリングと再テストに何時間もかかるからです。

これらのプロパティを表示するビューを含むデータクラスを使用して、関連するプロパティをグループ化することから始める方が適切です。 データクラスを作成すると、アプリケーションのケースタイプ間で再利用が進みます。 また、データクラスはアプリケーションの保守性を向上し、メンテナンスを簡素化します。

ケースの主な目的の1つは、特定のデータセットを管理することです。 データの管理は、データとして存在することとは役割が異なります。 データの主な目的は、1つ以上のケースで使用されることです。

ケースには2種類のプロパティがあります。

トランザクションの状態と履歴については、新しいプロパティを定義する必要はほとんどありません。

特定のシナリオでは、ライフサイクルや動作がほとんどないケースタイプを定義して、主にデータをローカルに保存するためにケースタイプを使用する場合があります。 ケースライフサイクルは、PyStatusWorkをNewからOpen to Resolved-Completedに変更して構成される場合もあります。 その場合は、SLA（サービスレベルアグリーメント）付きの単一のアサインメントを持つ可能性があります。

一見ケースが単純そうであると、Data Relationshipフィールドタイプを追加する必要もなさそうですが、 Build for Changeでは、常に1つ以上のData Relationshipフィールドタイプをケースタイプに関連付けることがベストプラクティスです。 Data Relationshipフィールドタイプの1つを、このケースタイプと同義にしてください。 これで、ケースタイプにおけるスカラープロパティを回避できます。  

たとえば、静的情報（製品の保証条件など）を含むData-Warrantyインスタンスは、読み取り専用です。 一方、Data-Warranty-Claimインスタンスは、PurchaseDate、ClaimDate、ExpirationDate、Expiredといった動的に変化するプロパティを含んでいます。 これらの追加プロパティを表示するビューでは、最初の2つは変更可能です。 一方、2つ目のセットのプロパティは計算されたものであり、読み取り専用です。

Event Bookingアプリケーションのサンプルもこのパターンに従っています。 FSG-Data-Hotelインスタンス内のフィールドは、Eventケースの観点からは静的です。 一方、RoomsRequestインスタンス内のフィールドは動的です。

また、ケースのデータモデルは、顧客データがあるケースから別のケースに伝搬されやすいことも考慮する必要があります。 フィールドグループは、サブケースやスピンオフケースを作成する直前に入力できます。 この方法で使用するフィールドグループは、最低でもワークプールクラスレベルで定義する必要があります。 サブケースまたはスピンオフケースがケースタイプのコンポーネントの拡張である場合は、フィールドグループの適用対象クラスは、たとえばWork-Cover-のように、より一般的なクラスにする必要があります。