複数のドメインのクラス間の通信が同じ基盤のDBテーブル

Question

WebUIプロジェクトとドメインとして機能するクラスlibプロジェクトを持つVS2015ソリューションがあります。クラスlibには、20個以上のEF DBファースト生成クラス（edmxモデル）と、これらのクラスで動作する20個のrepoがあります。基礎となるdbを変更する必要があるとき、私はedmxモデルを投げ捨てて再生成します。これらのクラスの1つはDomain.DbEntities.plcです。私のwebUIはこのドメインlibを参照しています。

は、いくつかの時間後、私はDomain libへの参照を持ち、メソッドパラメータとして、いくつかの受け入れDomain.DbEntities.plcまたDomain.DbEntities.plcを使用する一部戻すラッパークラスを有する溶液に余分なプロジェクトPlcCommunicatorを添加しました。私のwebUIプロジェクトは "PlcCommunicator"プロジェクトを参照しており、すべて正常に動作します。

解決策はますます大きくなっており、私はそれを参照してより多くのプロジェクトを追加して同じものを使用しています。Domain libしかし、今私はPlcMonitoringLoggerと呼ばれる別のプロジェクトを追加しました。私はもう一つの小さなドメインを作成することにしました。メインドメインのサブセットだけを作成しました。これは、すべてがEF DBでもある5クラスを保持します。Main Domainと同じdbで生成されたedmxクラス。これらのクラスの1つはPlcMonitoringDomain.DbEntities.plcです。 （Domain.DbEntities.plcとの違いに注意してください）

今私はPLCCommunicatorプロジェクトを使用する私のPlcMonitoringLoggerプロジェクトが必要です。しかし、PlcCommunicatorはDomain.DbEntities.plcで、PlcMonitoringLoggerはPlcMonitoringDomain.DbEntities.plcとしか分かりません。だから私は直面している問題があります....私はDomain.DbEntities.plcオブジェクトの代わりにplcのIDを受け入れるようにPlcCommunicatorメソッドのパラメータを変更することができますまたDomain.DbEntities.plcオブジェクトの代わりにplcのIDを返します。しかし、これは正しいアプローチですか？落とし穴がありますか？長所と短所は何ですか？もう1つの解決策はbase plc classを作成することですが、これは正しいとは思われません。私はお互いから物事を切り離して、baseクラスを作成するだけで、気分が良くないと思う。

制限付きコンテキストについていくつか読んでいます。しかし、私は既存のプロジェクトをすぐにこのデザインパターンを使用するように変更することはできません。なぜなら私はまだそれに経験がないし、初心者にとっては難しいから最後の場所ではありません。私は境界を越えた文脈からいくつかの側面を使うことへの「ベビー・ステップ」を全面的なリビルドを行わない最良のアプローチと考えています！

誰かがこのトピックまたは何か有用なものについていくつかのアイデアを持っていたら、お答えください！

Answer 1

サブドメインを作成することで何を達成しようとしたのか分かりませんが、その結果、それらは入れ替えることができません。ですから、もしあなたがドメインミックスアップをもたらすコンポーネントを結合したいなら、それはできません。

IMHOの解決策は、サブドメインを取り除き、それを現在のメインドメインに統合することです。ドメインを使用するプロジェクト/コンポーネントは、ドメインを使用する他のコンポーネントも問題なく参照できます。複数のドメインが混在することはありません。