コードインターフェイス駆動設計
接続性を減らし、SOAについて考えることで、インターフェイスを構成することで型を構築するというアイデアを思いつきました。
従来のDDDでは、ドメイン、つまりオブジェクトのコレクションとそれらの関係を強調する必要があります。 しかし、この原則を人生に適用すると、2つの困難に直面しました。
片道 -サービスとそのエンティティを1つのモジュールに結合します。 2つのアセンブリ（ドメインとサービス）または1つの単一のアセンブリになります-関係ありません。 目標は、アプリケーションの構成が実行されるアセンブリ（たとえば、AppCore）に参照を追加するだけで、モジュールのすべての機能を接続することです。
これを行った後、異なるモジュールのドメイン間の通信の可能性を何らかの形で残す必要があります。 この例では、User型のCar.Ownerプロパティを実装し、House.Owner、CableTv.Userなどを実装する必要がある可能性があります。 メンバーシップへの参照を追加することはオプションではありません。モジュールの接続を許可しないという主な考えと矛盾します。
アセンブリ内のこのような依存関係をすべて選択しますが、エンティティ全体ではなく、ダミーインターフェイスを使用します。 この例では、これは空のIUserインターフェイスになります。 次に、各モジュールの初期化中に（そのBootstrapperで）、モジュール内で指定されたもの（ICarOwner）でこのインターフェイスを展開します。ここで、このモジュール内のユーザーに必要ないくつかのプロパティを指定できます。
したがって、各モジュールは、独自のフィールドでIUserインターフェイスを補完します。 次に、インターフェイスのリストに基づいて、AppCoreにキャッシュされる単一のユーザータイプを作成するファクトリを実装する必要があります。
+各モジュールは、必要なフィールドのみを知っている
+基本的なインターフェースを除き、モジュールは完全に独立しています。
+新しいモジュールを追加すると、永続化に必要なプロパティが自動的に追加されます。 つまり モジュールを追加すると、Sql-schemeに必要なテーブル、列、その他のオブジェクトが自動的に補充されます。
-アイデアはまだ実装されていません=）。 しかし、このアプローチを実装したい人にとっては、これはプラスになります-彼はそれを実現する最初の人になります。
目標は、プラグアンドプレイ機能を作成することです。
Ordersが必要です-OrdersLibへの参照を追加し、起動しました、それだけです！
データベースは、OrdersLibの作業に必要な新しいテーブル、列、リンクで自動的に更新されます。 ユーザーは自動的にUser.Ordersなどを持ちます。
コードを適合させる作業はなく、必要に応じて拡張のみを行います。
Userオブジェクトの構成を理解する方法は？ 次の2つのオプションがあります。
最初の方法は厳密な型指定を保持し、2番目の方法は開発を完全に動的にします。
従来のDDDでは、ドメイン、つまりオブジェクトのコレクションとそれらの関係を強調する必要があります。 しかし、この原則を人生に適用すると、2つの困難に直面しました。
- 大きなドメインとその周りに多数のサービスがある場合、クラスメンバーへのアクセスを制御することが難しくなります。 次のようになります。CreatedAtプロパティを持つUserオブジェクトがあり、MembershipServiceのみが編集できるようにします。 それでは、MembershipServiceを示すInternalsVisibleToを作成します。 次に、PassedDistanceプロパティを持つCarなどのオブジェクトを作成する必要があります。このプロパティをCarService専用に開きます。 InternalsVisibleToを使用して操作を繰り返しますが、ここで問題が発生します。Membersipは車の燃費を変更でき、CarServiceはユーザー登録の日付を変更できます。
- DDDでは、必要なモジュールを接続するだけで、「ブリックバイブリック」アプリケーションを構築することはできません。 Rubyでも可能だと言われているので、.Net =）でも同じように簡単にしたいです。 ただし、同じ理由で機能しません。ドメインは別のアセンブリに割り当てられます。サービスに接続するときは、ドメインからすべての依存エンティティを手動でプルし、プロパティをソートする必要があります。 それらのほとんどは、新しいプロジェクトでは必要ありません。 つまり DDDはサービス接続の問題を解決しますが、ドメイン接続はまだ解決されていません。
片道 -サービスとそのエンティティを1つのモジュールに結合します。 2つのアセンブリ（ドメインとサービス）または1つの単一のアセンブリになります-関係ありません。 目標は、アプリケーションの構成が実行されるアセンブリ（たとえば、AppCore）に参照を追加するだけで、モジュールのすべての機能を接続することです。
これを行った後、異なるモジュールのドメイン間の通信の可能性を何らかの形で残す必要があります。 この例では、User型のCar.Ownerプロパティを実装し、House.Owner、CableTv.Userなどを実装する必要がある可能性があります。 メンバーシップへの参照を追加することはオプションではありません。モジュールの接続を許可しないという主な考えと矛盾します。
ソリューションのアイデア
アセンブリ内のこのような依存関係をすべて選択しますが、エンティティ全体ではなく、ダミーインターフェイスを使用します。 この例では、これは空のIUserインターフェイスになります。 次に、各モジュールの初期化中に（そのBootstrapperで）、モジュール内で指定されたもの（ICarOwner）でこのインターフェイスを展開します。ここで、このモジュール内のユーザーに必要ないくつかのプロパティを指定できます。
したがって、各モジュールは、独自のフィールドでIUserインターフェイスを補完します。 次に、インターフェイスのリストに基づいて、AppCoreにキャッシュされる単一のユーザータイプを作成するファクトリを実装する必要があります。
長所と短所：
+各モジュールは、必要なフィールドのみを知っている
+基本的なインターフェースを除き、モジュールは完全に独立しています。
+新しいモジュールを追加すると、永続化に必要なプロパティが自動的に追加されます。 つまり モジュールを追加すると、Sql-schemeに必要なテーブル、列、その他のオブジェクトが自動的に補充されます。
-アイデアはまだ実装されていません=）。 しかし、このアプローチを実装したい人にとっては、これはプラスになります-彼はそれを実現する最初の人になります。
目標は、プラグアンドプレイ機能を作成することです。
Ordersが必要です-OrdersLibへの参照を追加し、起動しました、それだけです！
データベースは、OrdersLibの作業に必要な新しいテーブル、列、リンクで自動的に更新されます。 ユーザーは自動的にUser.Ordersなどを持ちます。
コードを適合させる作業はなく、必要に応じて拡張のみを行います。
Userオブジェクトの構成を理解する方法は？ 次の2つのオプションがあります。
- ファクトリーの作成を簡素化する共通インターフェースのコード生成
- 開発されたアプリケーションの環境での開発。 Intellisenseはバイトコードを読み取らず、動的オブジェクトの実際のインスタンスを読み取ります。
最初の方法は厳密な型指定を保持し、2番目の方法は開発を完全に動的にします。
All Articles