ドメインとは何ですか？
この用語は、ソフトウェアアーキテクチャ（「ドメインモデル」、「ドメイン駆動設計」など）のコンテキストでよく見ます。私はそれをグーグルで調べました、しかし私はたくさんの異なった定義を得ます。それで、それは本当に何ですか？
Eric EvansによるDomain Driven Design本の「ドメイン」という言葉には特定の意味があります。それがソフトウェアの本質です。
エバンスはさらに進んでいます。彼の見解では、同じソフトウェアでもサブドメインがあります。そして、これは「戦略的デザイン」を扱う本の一部です。
コアドメイン、サポートドメイン、および汎用ドメインの3つの「ドメイン」があります。時々、彼はこれらをサブドメインと呼ぶでしょう。
Evansは、ソフトウェアの背後にある実際のビジネスにも深く関心を持っています。この本は、開発者だけでなく、ソフトウェアとビジネスがどのように連携するかを理解する必要があるアーキテクトやマネージャーも対象としており、戦略設計について話し合うときに気になります。そしてこれらのサブドメイン。
したがって、コアドメインはソフトウェアの一部であり、ソフトウェアの競争上の優位性と「存在理由」の両方を表します。これはソフトウェアの一部であり、顧客がそのソフトウェアを他のソフトウェアと比較して購入する理由です。通常、Evansはそれをコードのパーセンテージが最小のドメインと見なします。あなたはそれを最も重要な20％と考えることができます。これは実際に購入できない部分であり、ソフトウェア全体の単一のモジュールまたはコンポーネントにすぎない場合があります。
サポートドメインは依然として重要であり、組織に固有である可能性がありますが、コアドメインほど重要ではありません。それがなければ、ソフトウェアはそれほど価値がなく、コアはそれに依存しています。自分で作成したソフトウェアの複数のモジュールで、コアに対して重要であるがサポートする機能を実行する可能性があります。
汎用ドメインは、ソフトウェアの中で最もカスタム性が低く、ある意味で最も重要でない部分です。社内で作成した可能性もありますが、すぐに購入するか、よく知られているオープンソースソフトウェアを使用する方が効率的です。システムのこの部分はおそらくドメイン全体に固有のものではないため、たとえば、荷物を配送する配送システムや患者を管理する健康記録システムがある場合でも、一般的なドメインはこれらのシステムの一部であり、一般的であり、単に機能するためにそこにいる必要があります。これはおそらくシステム全体の大部分を占めますが、必ずしもそうではありません。
ビジネスの観点からは、コアドメインとは何かを決定し、そこに開発リソースを集中させることが重要です。 Evansは、特にInfoQサイトで多くのビデオを公開しており、そこで彼はこれらの概念をより詳しく説明しています。
したがって、ソフトウェアの「ドメイン」についてよく話しますが、DDDの場合は、見かけほど単純ではありません。
DDDの概念は、必ずしも幅広いソフトウェアコミュニティに存在するわけではないことに注意してください。他の開発者、作者、および製品の人々は、さまざまなアイデアや定義を持っている場合があります。 DDDについて書いた他の執筆者でさえ、エヴァンスの本でこれらの概念をよく理解しているかもしれませんが、ソフトウェアプロジェクトを書いたり計画したりするときは、その概念がまだ役立つと思います。
domainは、ソフトウェアを使用して問題を解決しようとしている実際のコンテキストです。各ドメインには、そのドメインの一部である専門知識、語彙、ツールが付属しています。
ドメインの具体的な例は、「高速回転カッターを使用した複雑な部品の自動加工」のようなものです。これを実現するソフトウェアおよびハードウェアシステムは [〜＃〜] cnc [〜＃〜]mill と呼ばれます。
ドメインのもう1つの例は、企業の経理部門です。
これは単に、作業している問題の領域を意味します。たとえば、eコマースのWebサイトを構築している場合、ドメインは「eコマース」であり、クライアント/会社の営業慣行に関連するプロセスが含まれます。したがって、ドメインモデルは、製品、請求書、または出荷記録を表すものになります。
A Domain is an area of knowledge. It can be though about as an activity in which problems solved by your software exist. ( Wiki , DDD Community )
Eric Evansは彼の著書で、貨物輸送を使用してDDDとは何かを説明しています。彼の例では、domainがshippingのすべてです。貨物の移動、管理、出荷、追跡など。独自の特定のルール、言語、プロセスが付属しています。これらは、ドメインモデル、オブジェクト、サービスなどを作成します。
アプリケーションを作成すると、実際の出荷の世界と同じように、ある種の権限が与えられます。誰もが倉庫にアクセスできるわけではありません。情報は貨物の輸送に関連しない可能性があるため、ユーザーの承認方法とアクセス許可の付与方法はドメインの外でもかまいません。
簡単に言うと、domainは、businessを行う場所です。あなたのビジネスが貨物の輸送である場合-貨物の輸送はあなたのドメインになります。あなたのビジネスが人員の認証と承認をしているなら、これがあなたのドメインになります。
ドメイン駆動設計：ソフトウェアの心臓部の複雑さに取り組む から、Eric Evans：
すべてのソフトウェアプログラムは、そのユーザーの何らかの活動または関心に関連しています。ユーザーがプログラムを適用する対象領域は、ソフトウェアのdomainです。
航空会社予約プログラムの領域には、実際の飛行機に乗る実際の人々が含まれます。
会計プログラムのドメインはお金と金融です。
ソースコード管理システムの領域は、ソフトウェア開発そのものです。
ドメインモデルは、ドメインエキスパートの頭の中の知識を「厳密に組織化され、選択的に抽象化したもの」です。
パレルモは、タマネギのアーキテクチャを説明する際に、この要約を提供しました
真ん中には、組織の真実をモデル化する状態と動作の組み合わせを表すドメインモデルがあります。
ファウラーは、
動作とデータの両方を組み込んだドメインのオブジェクトモデル。
より最近の定義を見ていると、 ドメインモデルとデータモデルが異なる の参照に遭遇する可能性が高くなります。強調の変更ほどの意味の変更ほどの意味の変更は考慮していません-動作のモデル化（モデルの外部からの情報に応じてデータが変化する方法）は、さまざまな書き方よりも複雑さとバリエーションが豊富です。
おそらくすでにドメインとは何かを理解しているので、次のステップとして、サブドメイン、ドメインモデル、さらに重要なのは境界付きコンテキストを定義しようと思います。
私はドメインの私の視点を置くことから始めます。
ドメイン
ドメインは私たちが住んでいる現実です。その実体、行動、従う法則。それは私たちの前に存在し、その後何らかの形で私たちの後に存在します。その存在は私たちの意識に依存しません。マーケティング担当者は新機能を考え出し、市場分析を実行します。主要なアカウントマネージャーはクライアントと通信し、ソフトウェア開発者はビジネスプロセスを自動化します。そのため、ドメインは問題空間と呼ばれます。
サブドメイン
DDDは、モデリングと理解を容易にするために、ドメインをサブドメインに分解することを意味します。ビジネスを運営しているという事実自体が、少なくとも1つの主要なビジネス価値があることを示しています。お金を稼ぐ人。私たちが事業を始めたもの。したがって、「コアドメイン」のような単語を知らなくても、存在します。同じことがサブドメインにも当てはまります。おそらく、簿記、人事、技術サポートが必要になりますが、それは二次的なものです。
ドメインモデル
抽出されたサブドメイン全体をモデル化する必要はありません。関心のあるサブドメインごとに特定のルールセットがあります。特定のビジネス結果を達成するために必要なサブドメインのルールセットは、モデルと呼ばれます。
境界付きコンテキスト
最も重要なことは、境界のあるコンテキストが論理的な境界であることです。
サブドメインとコアドメインの両方が定義されたら、コードを実装します。境界付きコンテキストは、いくつかのサブドメインの適用可能性の具体的な境界を定義します。これは、特定のサブドメインには意味があるが、他のサブドメインには意味がない領域です。それは、トーク、プレゼンテーション、アーティファクトによって定義される物理的な境界を持つコードプロジェクトです。
次は何ですか？
境界コンテキストの概念とサブドメインの概念の相関関係、サブドメインと境界コンテキストの定義方法、相互のコミュニケーションの表現方法、およびこれらの概念を念頭に置いてチームを編成する方法に興味がある場合は、おそらくこれに興味があるでしょう。 さらに読む 。