ルールは、流体です。インターネットは、それはすべての既存の技術革新にルールを再構築することができ、素晴らしいです。
アウトライン
大規模な業務システムでは、複数のサービスは、多くの場合、理解するシステムが困難、複雑、互いに交差しています。一般的なアプローチは、コードを読み取ることにより、システムの動作を理解することです。しかし、このアプローチには限界があります。プロジェクトコードなので、システムが頻繁に設計されており、ビジネスのミックスを実現し、正確なビジネスそのものを表現していません。
- 技術とシステムアーキテクチャの時間的な制約のために、多くの場合、最適なビジネスの視点を得るが、妥協はありませんでし。
- コード書かれた表現の比較的低い部分は、さえBUG正確ではありませんが、ビジネスそのものの真の理解を妨げます。
本当に、ビジネスを理解し、ビジネス自体、「ビジネスルール」を厳密に区別し、「設計と実装」から立ち上がっの必要性を理解するためには2つの異なるレベルです。プロジェクトのコードは、重要な基準として使用することができます。
三つの要素
データモデル
データモデルは、これらのデータ項目を整理する方法秩序やデータ項目は、必要とするデータ項目間の関連性を指します。データモデルは、ナビゲーション地図ソフトの全体的なデザインです。優れたデータモデルを識別し、デザインが大きな成功を収めています。
たとえば、次のように基本的なデータモデルのトランザクションがあります。このモデルにより、式はそれぞれのベースモジュールに関連するデータのすべての基本的な交換の全体の概要、および実質的に全体把握することができます。
具体的な事業のために、より容易に理解し、分析することができます。データの特定のビジネスモデル、通常、基礎となるデータモデルとデータセットのいくつかの拡張機能。
どのようにデータモデルを抽出するには？
DO、DTO、サービス・インターフェースの多様からのプロジェクトコードは、データオブジェクトを開始返します。各フィールドの精査の意味は、それが分類されます。このとき、選択的な読書を使用して、コード提示キーオブジェクトではなく、シャトル厄介なコードを読んで、黒と青を得ます。
ルール
ルールは、データ項目とプロセスがどのような制約を満たすことを意味しますか？サービスの目標は何ですか？
たとえば、オンライン取引を構築するために、プロセスは、単一のトランザクションが必要です。単一のトランザクション・プロセスの定義の下： - >情報を補完する - >価格 - >落下のための - キャリブレーションパラメータ>成功の順序を作成するためのメッセージを送信します。ルールである、プロセス。
注文プロセスをより完全な数を拡張することができます。お店に入る - >ビジネスの詳細ページをクリックします - > [ご注文を提出 - - >確認ページをご注文に行く>支払 - >注文決済結果ページをジャンプします。このプロセスは、このようなお店、商品、お支払い、プロモーション、物流、他のメンバーのような、より基本的なサービスを、必要とします。
あなたはまた、より完全な基本的なオンライントランザクション処理を定義することができます。注文 - >支払 - >出荷する - >出荷 - >受信されている - >トランザクションの完了、またはオーダー - >入金 - >が出荷される - >払い戻し - >契約は終了しました。
プロセスに加えて、だけでなく、データ項目間の制約規則を指します。このような価格として、その上のシーンをサポートしていない、値引き、返金チェックの間で計算。
最も重要なポイントのルールは以下のとおりです。ルールは、流体です。厳格に既存のルールを遵守しないでください。あなたは完全に新しいルールを作成することができます。たとえば、オンライン取引は、ルールのセットで、オフライン・トランザクションは、一連のルールで、社会的な取引に基づいて、おそらく新たな取引ルールを生成する、AIの人気の後、将来的にルールのセットです。
ルールを抽出する方法は？また、それは、コードから抽出する必要があります。
プロセス。まず、基礎として最も一般的な抽出プロセス;次に、どのように行うか、カットまたはカスタムを見てください。支払いが成功し、すぐに出荷されることなくなって出荷された後は、そのようなバーチャルグッズなど;例えば、グループの売上高になるためにグループに余分な状態にあることを支払った余分から出荷される注文などのグループを戦います。
判決。コードはのif-elseスローの様々なから抽出することができます。
抽出ルールの後、あなたはルールを定義する理由について慎重に検討するために、これは背後にある意図と目的は何ですか？
セマンティック
優れた拡張し、システム開発の機能するためには、データモデルとルールを構築した後、データ項目と意味規則の明確かつ明確な定義が必要。より慎重になるデータのセマンティクスの3つのタイプがあります。
- クラス状態の意味。このような注文状況として、通常の事業の循環を必要とする、私たちは、スケーラビリティを考慮する必要があり、新しい状態を簡単にサポートすることができ、新たな事業。
- クラスのセマンティクスの量。例えば、原因金額と実際に支払った金額。複数の重複事業の場合、明確なセマンティクスの欠如、量クラスフィールドが複数の値と理解している可能性がある場合は、それが簡単に資金の故障につながることができます。資金の失敗は、多くの場合、最も深刻な障害カテゴリの一つです。
- 意味カテゴリを特定します。エンティティを一意に識別するために使用されるクラスのフィールドを識別する。
「+セマンティックデータモデルとルール」によって、あなたは、基本的なサービスシステムサービスの画像の輪郭を描くことができます。
プロジェクト戦闘
調理しないでください、調理することを学ぶことはありません。
「+セマンティックデータモデルとルール」によって、ビジネスの基本的な理解を得ることができます。しかし、これは多くの場合、理解を明確にぼやけています。プロジェクトの戦闘、精査特定のビジネス実装の詳細、より深く理解することで、既存のデータ・モデル、ルール、意味論的な意味と理由を拡張します。
具体的な事業のために、このような考え方は、フレームを分析するために使用することができます。しかし、これらは一般的な部分に基づいており、外に伸びている「セマンティックデータモデル+ +ルール。」
概要
データモデル+ +セマンティックルール：このホワイトペーパーでは、ビジネスの考え方を理解するための効果的な枠組みを提示しています。「+セマンティックデータモデルとルール」によって、あなたは、基本的なサービスシステムサービスの画像の輪郭を描くことができます。プロジェクトコードの実現に限定されるものではなく、より容易にアクセス可能なビジネスの真の意図や目標に理解するために、ビジネス自体からのデータ、および意味規則にコミットされるわけではありません。