この用語は、ソフトウェアアーキテクチャ（「ドメインモデル」、「ドメインドリブンデザイン」など）のコンテキストでよく見られます。私はそれをグーグルで調べましたが、さまざまな定義がたくさんあります。それで、それは本当に何ですか？

Eric EvansによるDomain Driven Designブックの「ドメイン」という言葉には特定の意味があります。それがソフトウェアの目的です。

エヴァンスはさらに進んでいます。彼の見解では、同じソフトウェアでもサブドメインがあります。そして、これは「戦略的デザイン」を扱う本の一部です。

コアドメイン、サポートドメイン、および汎用ドメインの3つの「ドメイン」があります。彼はこれらをサブドメインと呼ぶこともあります。

Evansは、ソフトウェアの背後にある実際のビジネスにも深く関心があり、この本は開発者だけでなく、ソフトウェアとビジネスがどのように連携するかを確認する必要があるアーキテクトやマネージャーも対象にしています。およびこれらのサブドメイン。

したがって、コアドメインは、ソフトウェアの競争上の優位性と「存在理由」の両方を表すソフトウェアの一部です。顧客がソフトウェアと他のソフトウェアを購入するのは、ソフトウェアの一部です。通常、エヴァンスはそれをコードの割合が最小のドメインと見なします。最も重要な20％と考えることができます。これは実際に購入できない部分であり、ソフトウェア全体の単一のモジュールまたはコンポーネントである可能性があります。

サポートドメインは依然として重要であり、組織に固有のものであってもかまいませんが、コアドメインほど重要ではありません。それがなければ、ソフトウェアはそれほど価値がなく、コアはそれに依存します。自分で作成したソフトウェアの複数のモジュールで、コアに対して重要であるが支援的な機能を実行する可能性があります。

汎用ドメインは、ソフトウェアの中で最もカスタマイズが少なく、ある意味では最も重要ではありません。社内で作成したかもしれませんが、そのまま購入するか、有名なオープンソースソフトウェアを使用する方が効率的かもしれません。システムのこの部分は、おそらくドメイン全体に固有ではないため、たとえば、小包を配送する配送システムや患者を管理する健康記録システムがある場合、汎用ドメインはこれらのシステムの一部であり、一般的であり、単に機能するためにそこにいる必要があります。これはおそらくシステム全体の大部分を占めていますが、必ずしもそうではありません。

ビジネスの観点からは、コアドメインとは何かを決定し、そこに開発リソースを集中することが重要です。Evansには、特にInfoQサイトで多くのビデオがあり、これらの概念について詳しく説明しています。

したがって、DDDの場合、ソフトウェアの「ドメイン」についてよく話しますが、見た目ほど単純ではありません。

DDDの概念は、より広範なソフトウェアコミュニティに必ずしも存在するわけではないことに注意してください。他の開発者、作成者、および製品担当者は、さまざまなアイデアや定義を持っている場合があります。DDDについて書いた他の著者でさえ、Evansの本でこれらの概念を詳しく説明しているかもしれませんが、ソフトウェアプロジェクトを作成および計画する際にこれらの概念はまだ有用だと思います。

ドメインは、あなたがソフトウェアを使用して問題を解決しようとしているれている実世界のコンテキストです。各ドメインには、そのドメインの一部である専門知識、語彙、ツールが付属しています。

ドメインの特定の例は、「高速回転カッターを使用した複雑な部品の自動加工」のようなものです。これを実現するソフトウェアおよびハードウェアシステムは、CNC ミルと呼ばれます。

ドメインの別の例は、企業の経理部門です。

マーティン・ファウラーによる境界コンテキストの詳細

たとえば、eコマースのウェブサイトを構築している場合、ドメインは「eコマース」になり、クライアント/会社の営業慣行に関連するプロセスが含まれます。したがって、ドメインモデルは、製品、請求書、または出荷記録を表すものになります。

ドメイン知識の領域です。それはあなたのソフトウェアによって解決された問題が存在する活動としてであるかもしれません。（Wiki、DDDコミュニティ）

エリック・エヴァンスは著書の中で、貨物輸送を使用してDDDについて説明しています。彼の例では、ドメインは配送に関するすべてです。貨物の移動、管理、出荷、追跡などの方法。貨物には独自の特定のルール、言語、プロセスがあります。これらは、ドメインモデル、オブジェクト、サービスなどを作成します。

アプリケーションを作成すると、実際の配送の世界と同様に、何らかの許可が与えられます。誰もが倉庫にアクセスできるわけではありません。情報は貨物の輸送に関連していない可能性があるため、ユーザーがどのように許可され、許可がどのように付与されるかはドメイン外である 可能性があります。

簡単に言えば、ドメインはビジネスを行う場所です。あなたのビジネスが貨物を出荷している場合-貨物の出荷があなたのドメインになります。あなたのビジネスが従業員の認証と承認を行っている場合、これがあなたのドメインになります。

ドメイン駆動設計：ソフトウェアのハートに複雑への取り組み、エリック・エヴァンス：

すべてのソフトウェアプログラムは、ユーザーの何らかの活動または関心に関連しています。ユーザーがプログラムを適用するサブジェクト領域は、ソフトウェアのドメインです。

航空会社の予約プログラムの領域には、実際の航空機に乗る実際の人々が含まれます。

会計プログラムの領域はお金と金融です。

ソースコード管理システムの領域は、ソフトウェア開発そのものです。

ドメインモデルは、ドメインの専門家の頭の中の知識を「厳密に組織化された選択的な抽象化」です。

パレルモは、タマネギのアーキテクチャを説明する際に、この要約を提供しました

真ん中には、組織の真実をモデル化する状態と動作の組み合わせを表すドメインモデルがあります。

ファウラーは、順番に、提供しています

動作とデータの両方を組み込んだドメインのオブジェクトモデル。

最新の定義を見ると、ドメインモデルとデータモデルが異なる参照に遭遇する可能性が高くなります。意味の変化は、強調の変化ほど重要ではありません-行動のモデル化（モデルの外部からの情報に応じてデータが変化する方法）には、物事を書き留めるさまざまな方法よりも複雑で変化があるとは考えていません。

おそらくドメインとは何かを既にご存知だと思いますので、次のステップはサブドメイン、ドメインモデル、さらに重要なことには境界付きコンテキストを定義することです。

ただし、ドメインの視点を置くことから始めます。

ドメイン

ドメインは私たちが住む現実です。その実体、その行動、従う法律。それは私たちの前に存在し、何らかの形で私たちの後に存在します。その存在は私たちの意識に依存しません。マーケティング担当者は新しい機能を考え出し、市場分析を実行します。キーアカウントマネージャーはクライアントと通信し、ソフトウェア開発者はビジネスプロセスを自動化します。それが、ドメインが問題空間と呼ばれる理由です。

サブドメイン

DDDは、モデリングと理解を容易にするために、ドメインをサブドメインに分解することを意味します。ビジネスを運営するという事実は、少なくとも1つの支配的なビジネス価値があることを推測します。お金を稼ぐもの。私たちがビジネスを始めたもの。そのため、「コアドメイン」のような単語を知らなくても、それはまだ存在しています。サブドメインにも同じことが当てはまります。おそらく、簿記、人事、技術サポートが必要になるでしょうが、それは二次的なものです。

ドメインモデル

抽出されたサブドメイン全体をモデル化する必要はありません。関心のあるサブドメインごとに特定のルールセットがあります。特定のビジネス結果を達成するために必要なサブドメイン内のルールセットは、モデルと呼ばれます。

制限されたコンテキスト

最も重要なことは、境界のあるコンテキストが論理的な境界であることです。

サブドメインとコアドメインの両方が定義されたら、コードを実装します。境界付きコンテキストは、サブドメインの適用可能性の具体的な境界を定義します。これは、特定のサブドメインが理にかなっている領域であり、他のサブドメインはそうではありません。トーク、プレゼンテーション、アーティファクトによって定義された物理的境界を持つコードプロジェクトの場合があります。

次は何ですか？

バインドされたコンテキストの概念がサブドメインの概念とどのように相関するか、サブドメインとバインドされたコンテキストを定義する方法、相互のコミュニケーションを表現する方法、これらの概念を念頭に置いてチームを編成する方法に興味があるなら、おそらくあなたはこれに興味があるでしょうさらに読書。