1

エヴァンの本、ページ。430：

したがって、この例は分離されたコアに私たちを駆り立てるほど複雑ではないかもしれませんが...

a）作成者は、ドメインモデルが非常に複雑でない限り、分離コアを使用すべきではないことを示唆していますか？言い換えれば、複雑なドメインモデルを扱わない限り、コアドメインはドキュメントの形式（つまり、ドメインビジョンステートメントと強調表示されたコア）でのみ存在する必要がありますが、別個の物理エンティティとして明示されるべきではありませんか？

ありがとうございました

4

4 に答える 4

2

私にとって、分離されたコアとは、ドメイン コンポーネントを完全に個別のパッケージに編成することを指しますが、まとめて同じコア ドメインを表します。大規模なコアは、ドメインの構成を明確にするため、またはコア ドメインの概念からサポート機能を分離するために、このタイプの組織の恩恵を受ける場合があります。

于 2013-03-12T00:55:33.423 に答える
1

ページに。429 エヴァンスは次のように述べています。

分離されたコアを切り取るタイミングは、システムにとって重要な境界付けられたコンテキストが大きく、モデルの本質的な部分が多くのサポート機能によって隠されている場合です。

分離されたコアは、概念的によりまとまりのあるモデルに進化するようにコア モデルを改良することを目的とした、使用できるリファクタリング手法にすぎません。CORE DOMAIN を部分的にしか提供しない要素を別のサポート コンテキストに移動することは、分離されたコアが指示することです。

于 2014-12-21T17:53:22.580 に答える
1

「コア ドメインは、ドキュメントの形でのみ存在する必要があります (つまり、ドメイン ビジョン ステートメントと強調表示されたコア)」

いいえ。コア ドメインは、単なるドキュメント セットとして存在するべきではありません。これは、ドメイン駆動設計のポイントを無効にします。DDD の全体的なポイントは、ビジネス分析成果物がシステム内でファースト クラスの表現を持っていることです。たとえば、要件で ShippingCargo の Route の概念が定期的に議論されていて、 ShippingCargoとRouteのクラス(コード レベルのアーティファクト)がない場合、それは間違っています。ユビキタス言語のポイントは、ソフトウェアが行うと私たちが言うことと実際に行うこととの間に厳密なマッピングがあることです。

この手法は、認知負荷を管理し、さまざまな利害関係者によるシステムに関する用語と推論のインピーダンスの不一致を減らすことを目的としています。

モデルをドキュメントにのみ保持することは、 DRYに違反するケースです。コード コメントやそれらに対するさまざまな議論と同様に、ドキュメントは古くなり、価値を失います。これはいくら強調してもしすぎることはありません。DDD の要点は、コード以外のドキュメントからの最小限のサポートでコードがコア ドメインを明示できるようにすることです。

分離されたコアは、ドメイン オブジェクト (エンティティ、値オブジェクトなど) の数が非常に多くなり、まとまりとアーキテクチャの簡素化のために物事を分割することが理にかなっている場合に特に役立ちます。

このコンセプトの応用例

彼らのコード ベースの進化を見てください (状況がどのように変化したかを確認するには、過去 2 年間をブラウズする必要があるかもしれません)。これらのシステムが大きくなり、より多くの外部システムとインターフェースをとるにつれて、「コア」モジュールの考え方が重要になったことに気付くでしょう。それが分離コアです。

于 2013-05-24T19:59:31.540 に答える
0

ドメイン駆動型のパターンと方法論のセット全体は、複雑なビジネスドメインでのみ使用する必要があります。

「複雑」は、コードモデルが適切に設計されていない場合、またはドメイン駆動型アプリケーションに必要な表現度を提供しない場合に、コードモデルに適用できる蔑称です。さらに、ジュニアモデラーは、ビジネス自体の要点を見逃し、ビジネスよりも複雑なモデルを設計する可能性があります（多くの場合、柔軟性を求めて）。

大規模で複雑なドメインや、何年にもわたって進化したモデルを使用する場合、よく知られている技術的負債と同様に、小さなモデリング債務を累積することがよくあります。次に、（顧客の観点から）最も価値のある概念とビジネスルールのみを含む分離されたコアドメインに向けてリファクタリングすると、システムの進化がより安価になります（通常はそれ自体が高価なリファクタリングであっても）。

ただし、DDDが必要な場合は、仕様書を作成するだけではありません。複雑なビジネスを「ソースコード」と呼ばれる記号表現で表現することにより、それらを理解して処理するには、DDDが必要です。私のお金では、DDDは貴重なビジネス分析ツールですが、その要点は、複雑なビジネス上の問題を解決する貴重なアプリケーションのコーディングを可能にすることです。

于 2013-03-12T09:18:49.557 に答える