ニコライ・グレブネフ（CUSTIS）-DDDとは？ -ADD会議からのレポート

ADD （Application Developer Days）というカンファレンスがあり、ソフトウェア開発のためのあらゆる種類のアーキテクチャの部分について議論したいと思います。通常、これらの部分はxDD（DDD、TDD、MDDなど）で終わります。

たとえば、前回の会議で彼らは質問をしました：DDD（Domain Driven Design）とは何ですか？
そして、 CUSTISの ニコライ・ グレブネフ -立ち上がって答えた。

レポート動画：




ここからビデオをダウンロードできます（0.73 GB）

レポートのプレゼンテーション：


レポートテキスト

DDD（Domain Driven Design）とは何ですか？

これは、開発方法を定義するシステム、ビュー、アプローチのセットです。 2002年に、 Martin Fowlerは彼の著書、Enterprise Application Architecture Templatesをリリースしました。 この本は現在、エンタープライズアプリケーション開発のための古典的なアーキテクチャです。 特に、Martinは、プロジェクトのビジネスロジックを整理するための3つのパターンを提供します。

• トランザクションスクリプト
• テーブルモジュール
• ドメインモデル

トランザクションシナリオは、すべてのビジネスロジックをいくつかのビジネスオペレーションに分割するビジネスロジックを編成する方法です。実際、何らかの方法で自分の内部に配置され、入力でデータを受け取り、出力で結果を取得し、データベースのエントリなど、システムのいくつかの変更。



ここに、ビジネスロジックのこのような構造があります。かなり複雑なロジック、大量のアプリケーションを使用すると、このメソッドはうまく機能しません。パスタコード、「貼り付けの保存」などが必要になるためです。
テーブルモジュールは少し異なるアプローチです。 それは、クラス、私たちにとって関心のある概念のテーブル、実際にはデータベーステーブルを指定するエンティティを選択するという事実にあります。



すべてのクラスには何らかの操作があり、既に何かを知っており、何かをカプセル化しています。 原則として、データベースとの作業をカプセル化します。 特に、メソッドには、追加、削除、すべての取得、その他のメソッドが含まれる場合があります。 さて、各エンティティで、テーブルからクエリを実行して作業します。 明らかに、テーブル間の接続はなく、プログラム内で何らかの方法でテーブルを手動で構築します。 実際、誰かがMS Visual Studioで作業した場合、または一般にMSテクノロジーで作業した場合、これらはRecordSetとDataSetであり、2008年まではデータを操作するための主要なテクノロジーでした。
さて、 ドメインモデル 。 ここで示した以前のオプションとは異なりますが、ここでは本格的なドメインモデルを構築しています。 動作するエンティティ、他のエンティティと対話するエンティティ、明示的な関係を持つエンティティなどで構成されます。 この図は、ライブラリなどの自動化ドメインのモデルを示しています。



ドメインモデルは主にエンティティで構成されますが、サービス、値オブジェクトなど、さまざまなオブジェクトがまだあります。 さて、サブジェクトエリアのオブジェクトモデルについて話しており、企業のIPでは、ほとんどのサブジェクトエリアにオブジェクト構造があり、その大部分がエンティティで構成されていることがわかります。
エンティティは、アイデンティティを持つ概念です。 つまり 各エンティティインスタンスは識別可能で、他のエンティティインスタンスとは異なり、オブジェクトの状態とその動作をカプセル化します。 これは、オブジェクトの状態を変更する、一貫性のない状態にする、または何らかの方法で動作させないようにする方法をオブジェクトに通知することなく、決してできないことを意味します。
このテンプレートは、複雑なIPでの使用に最も適しています。 主題領域を最もうまく構成し、理解に貢献するからです。
2003年のこのテンプレートの開発として、 Eric Evans は「Object-Oriented Design」というタイトルの本を出版しました（元のドメイン駆動設計の構造化された複雑なソフトウェアシステム）。 この本には、サブジェクト領域としてのそのようなテンプレートの説明だけでなく、そのようなセット、ビルド、およびサブジェクト領域のこのモデルを最終的に取得する方法を示す方法のセットも含まれています。 これは、エリックエヴァンスがDDDについて語ったものです。
これは、第一に、 知識の処理です 。 私たちが主題分野について持っている知識、それらは分析される必要があり、実際の主題分野はそれらから選択されなければなりません。
第二に、それは単一の言語です。 どのモデルも、独自の言語を形成する用語を提供し、それを使用して作業し、話し、書きます。
モデルごとの設計（Model Driven Design） 。 これはDDDの最も技術的な部分です。 つまり、サブジェクトエリアの発明モデルをコードに直接マップします。つまり、他のモデルではなく、コードにマップします。

さて、これらの各部分をさらに詳しく見てみましょう。 名前から判断して、DDDはデザインであると考えられ、そこからモデルを取得したいと考えます。 実際、これはやや間違っています。 そして一般的に、これは不可能だと言えます。 すべてがもう少し複雑だからです。 サブジェクトエリアに来てそれを自動化する場合-どのモデルがあるかはまだわかりません。 さらに、彼女と一緒に働く特別なアナリストでさえ、彼らがどのモデルを持っているのかを知りません。 さらに、何らかのモデルは必要ありませんが、IPのモデルである必要があります。ほとんどの場合、一般に受け入れられているドメインモデルとは少し異なります。 より明確に制限され、より正式に定義された新しい概念または他の概念があります。したがって、DDDに従って開発するときに最初に行う必要があるのは、対象分野の知識の処理を開始することです。 サブジェクト領域の表現を自分で作成した後、モデルを設計する必要があります。モデルを使用して直接作業します。 モデルが設計された後、再びサブジェクトエリアに戻り、より詳細に、より詳細に、新しいエンティティの強調表示、明示的な暗黙の作成などを検討し始めます。最後に、リファクタリングすると、再び知識の処理に戻ります。 、再度、何をしたか、何を変更できるかを分析し、その後モデルを作成します。 そして、そのような反復プロセスが行われます。

知識処理とは何ですか？

エリック・エバンスが定義しているように、それは必要な詳細を考慮に入れた抽象的な概念の検索です。
明らかに、IPの開発に必要です。
誰がこの知識処理を実行しますか？

• ドメインスペシャリスト
• システム開発者（プログラマーという意味ではなく、アナリスト、テスター、プロジェクトマネージャーですが、システムアーキテクチャがどのようになるかを理解しているコードを作成する人がいることが重要です）

当然、開発者はこのプロセスを指示します。これは実際に必要だからです。 そして、彼らはシステムがどのように配置され、それをどうするかを正確に知っています。 対象分野の専門家は、それぞれがどのようにすべてを整理したかを伝え、必要な説明をします。

例
以下に例を示します。 モデルリサイクルとは何かを説明します。 これが最も簡単なタスクです-特定の月の従業員の給与を計算します。 これに遭遇したことのある人は、おそらく給与が私たちが望むほど簡単に計算されないことを知っています。
主題の専門家は、

月の就業日数に対する就業日数の比率に、月の就業日数に対する従業員の給与の比率を掛けたもの


モデルを構築しています



明らかに、そのフレーズには、従業員、月、就業日数、従業員の給与などの概念があります。
専門家に勤務日を尋ねます。 答えが得られます。
従業員が職場にいたが、まだ辞めなかった勤務日。



新しいエンティティがあります。それはある種のDAYです。明らかに、それははっきりと目立っており、従業員と月との関係を持ち、「仕事/休日」、「現在」という属性を持っています。
さらに、ドメインスペシャリストは、従業員がまだ休暇を取っているか、病気の休暇を取り、そこですべてが異なっている、率が異なる、その他の問題があることを思い出します。



私たちはそのようなモデルを描きますが、私たちに何かが間違っていることがすでにここに見えています-多くの接続。 質問するのは理にかなっています。 また、休暇中であろうと病気休暇中であろうと、従業員が職場にいたことをどのようにして見つけることができますか。 そして、スペシャリストは「タイムシートから」と答えます。 彼は彼にとって絶対に自然だったので、彼は彼に以前に言及していませんでした。 これは別の言及を必要とするものではありませんが、ここでは知識を処理し、システムを分析することにより、そのようなエンティティを特定しました。したがって、従業員がいる場合、取得するモデルはより理解しやすく、次の機能を持つタイムシートがあります以下の方法：

• 勤務日数を取得する
• 休暇の日数を取得する
• 病気休暇などの日数を取得する

そして、このレポートカードには、これらの日数のカウントに関連するすべてのロジックがカプセル化されています。 内部はすべて非常に複雑に編成されているため-とにかく、これは単純化されたモデルです。 そして、これらすべてをタイムシートにカプセル化し、その後、私たちは明確に特定し、明確に言ったので、専門家と話すときは専門家と冷静に話すことができます。

単一の言語は、DDDの結果として得られる言語です。 これは、すべてのプロジェクト参加者が互いに通信する言語です。 これは、何らかのモデルを構築し、それを捨てて、とにかく、いくつかの新しい用語で、指で何かを説明して話し始めるという意味ではありません。 いいえ、私たちは主題領域のモデルを持っています。それは、その用語、関係、行動において話し、技術的なタスクの構造などについて話し合うべきです。 この言語は、サブジェクト領域のモデルに基づいて構築されており、明確にそれに従う必要があります。 また、ドメインモデルもチェックします。 作成したサブジェクトエリアのモデルが非常に複雑で、言語で使用するのが難しい場合、他の用語や他の文を常に使用する必要があります。これは、モデルが正しく作成されていないことを意味します。 良いモデルがあるかどうかを確認する非常に良い方法は、その用語をロシア語で使用することです。 このモデルについて話してください。そこに不快感がなければ、すべてが順調です。 そして、このモデルはすべてのドキュメントで使用されます。 つまり 単にモデルを構築して話しているだけではありません。 いいえ、TK、要件、システムアーキテクチャなどを含む公式ドキュメントを作成するのは、これらのモデルに基づいています。 そして奇妙なことに、このまったく同じ言語をコードで使用する必要があります。 つまり 人と話すときにこのモデルをロシア語で使用した場合、コンピューターと話すときに同じモデルを使用する必要があります。
ドメインモデルがあり、用語を生成します。 概念、エンティティ、および動作で構成されているため。 辞書にある「用語」という言葉の定義の例を次に示します。

用語とは、特定の明確に限定された意味を持つ科学技術用語の単語である用語のシステムです。

これは、言語という言葉によって、このモデル、つまり相互に通信するために生成された言語を使用できることを意味します。 また、用語の意味が明確に制限されているという事実により、これらの用語をコードで使用する機会が与えられます。

モデルによる設計。

最も難しい部分はDDDです。 技術的な理由で、あらゆるものの不完全なツール、思考のthinking性、その他の多くの理由により困難です。 これがモデル設計です（Eric Evansによる）。
モデルによる設計（モデル駆動型開発） - プログラム要素とモデル要素の特定のサブセット間の最も正確な対応が観察されるアーキテクチャを設計します。
これは、ドメインモデルがあった場合


-そして、私たちは彼女のためにプログラムを作り始めます。



そして一度-私たちはちょうどそのようなモデルを取得します。 中央には、ビジネスロジックがあります。 まったく異なる概念が使用されていることがわかります。 ここに、ある種のデータセットがあります。 デイトライダー、チーム、コネクター、およびドメインモデルで言及されていなかったその他のもの。 対象地域の人々、このプログラムを書いている人々とこの言語を話そうとすると、あなたが何を意味するかを非常に長い間説明しなければならないということではありません。
そして、ここには、1つのモデルと別のプログラムがあることがわかります。 プログラムモデルは同じ概念（データセット、接続など）とドメインモデル（書籍、著者、出版社、読者など）で動作します。
これは、ドメインモデルを破棄する必要があることを意味します。もちろん、それは有用であり、ドメインモデルを構築した人々はドメインをよく知っていましたが、その関連性はすぐに失われます。
しかし、これはそうではなく、ドメインモデルの適用範囲ははるかに広くなっています。 エヴァンスの定義から：

モデル駆動型設計（MDD）は、オブジェクト指向プログラミング言語への主題言語の直接投影です。

つまり モデルにAuthorの概念がある場合、これは間違っています。コードでは、これはデータセットの文字列であり、型付けされていなくても明示的には存在しません。

例を挙げましょう。 次のタスクを作成しましょう。

指定された日付から、従業員をユニットに登録します。

会計システムの一般的なタスクであり、一部の部門が履歴を保持していること、ユニットの従業員を獲得できるようにする必要があることは容易に理解できます。 ユニットには、日付に従業員を登録するなどの機能があります。 通常そうであるように、コードでこれを書いてみましょう。



データセットでの作業も引用していませんが、いくつかのORMに基づいたモデルであり、Linqをサポートしているものの、実際のものとは若干異なります。 ご存知のように、プログラマーなら誰でもこれを行うことができます-従業員を登録するためにデータベースに保存されたすべての古い間隔を取ります-特定の日付から始まるすべての間隔を取り、削除する必要があります。 同時に、何が起こるかを見てください。 削除が表示されるだけでなく、削除が行われる前に、DeparmentHistroyRepositoryがあるためです。 おそらく、「リポジトリ」の概念は、多少なりとも主題領域に統合できますが、実際にはテーブルであり、部門ごとの情報を保存するこのような新しいエンティティは、モデルにとってすでに非常に悪いものです。
次に何をしますか？ 次に、従業員がユニットで働いていないことを伝えるために、彼が働いていた1日前に存在していた前の期間を完了する必要があります。



ドメインモデルには、select、where、from、from、DataEnd、DepartmentHistoryRepositoryなどの単語がまったくなかったことを認めなければなりません。 これらの概念はコード内にのみあり、すでに明らかな矛盾が見られます。 同時に、これらの操作の両方がタスクにまったく存在しないことに注意してください。これらは、技術的な必要性が原因です。
そして最後に、タスク自体を行い、本質を作成します



同時に、このエンティティを作成するのは一般的なユニットではなく、厳密に言えば、このユニットは誰かにクレジットされますが、一部のDepartmentHistoryRepositoryでは、プログラマだけがこれを知っており、すべてが可能ではない可能性が高いことに注意してください。 次に、別の名前でメソッドを呼び出します-"新規作成"（CreateNew）-なぜ新しいのですか？ 何も作成せず、単にその人を登録します。
しかし、モデルドライブデザインの場合、次のようになります。



ここで、たとえば-そのように。 ここでは、特にロシア語を使用して、ドメインモデルとコードで使用するものとの対応を可能な限り最大限に近づけました。 さらに、何らかの種類のロジックが存在する場合でも、このメソッドにカプセル化し、より詳細に開発する必要があります。 次に、このスタイルですべてのコードを記述します。 第一に、プログラミング言語に慣れていない人でも簡単に読むことができます-それは多かれ少なかれロシア語で書かれます。 ロシア語とは異なり、C＃は括弧、コンマ、ピリオドなどが異なります。 さまざまな間投詞、前置詞、その他の関連語に置き換えられます。
DDDとは何かを簡単に説明できるといいのですが。 これは、サブジェクトエリアを開発する際の知識の処理であることを思い出させてください。これは、私たち全員が常に相互に通信しなければならない単一の言語です。 ドメインベースのモデリング。つまり、このモデルを開発しただけでなく、コードに直接実装することを意味します。

なぜDDDが必要なのですか。

これは複雑さに対処する効果的な方法です。 実際、複雑なシステムでは-優れたドメインモデルだけで複雑性に対処できます。 そして、コードに直接実装する場合、プログラマー、アナリスト、ドメインエキスパートがすべて同じ用語で作業する場合、プログラマーは常に「リーダー作成者」からデータセット、レコードセットに変換する方法を考える必要はありません。 これは重要であり、プログラマーがまったく考えてはならないことではなく、明示的に分離するだけです。 何とは別に。 そして、これは単一の言語です。 この単一の言語には直接マッピングコードがあるため、このことの価値を過小評価しないでください。まあ、この言語で話すほぼすべてのフレーズは、純粋に投機的であってもすぐに確認できます。 コードで実装することは可能ですか？ 原則として、コードが他のいくつかの用語で記述されている場合、かなりの時間がかかります。 さらに、単一の言語自体、言語自体の存在により、要件の開発を大幅に改善できます。 かなりよく知られている事実は、プロジェクトの品質とプロジェクトの速度がスコープの適切な定義に依存していることです。ほとんどの部分はそこにありません。つまり、1つの用語がなければ何をするか、常に定義しません。私たちが話していることについて再交渉するたびに非常に困難です。
そして、これらすべてが最終的に開発と保守の低コストをもたらします。これはもちろん、企業情報システムの開発において非常に重要です。

多くの利点を説明してきました。 そして、なぜDDDを使用できないのか、なぜそれを拒否できるのか？ いくつか問題があります。 すべてが私たちが望むほど良いわけではありません。

短所DDD

組織の問題、たとえば分析と設計の分離、それは両方とも明示的である可能性があります-分析にまったく参加しておらず、分析に参加していなくても、明確にではなく、人の頭だけにあるアナリストと開発者がチームにいますが、彼自身のために、彼は最初にある種のモデルを分析して構築し、次にそれを実装しようとします。 そして、彼はそれを原則として何らかの形で実現しようとしています。 この場合、DDDを使用して、モデルをどのように実装するかをすぐに考えなければなりません。 また、たとえば、この形式ではモデルを実装できないことを理解している場合、パフォーマンスは非常に重要です。 次に、これらの新しい概念を明示的に、明示的に、明示的な用語で紹介し、それに基づいて顧客やプロジェクトの他のすべての参加者と話しますが、これらの新しい概念は非常に難しく、通常はある程度の経験が必要です。
開発者が分析から切り離されたときにも純粋に管理上の問題が発生することが多く、開発者は一般に、アナリストの別の部門が選ばれたときに、誰がこれを行っているのかまったくわかりません。 これはそれほど悪いことではありませんが、必要な数の技術的詳細に精通していないため、原則としてアナリストは、アーキテクチャを最初から最後まで表現せず、構築できません。 このため、アナリストがコードで実装できないモデルは、実装の機能を考慮していないため、間違いなくする必要があります。 そのため、アプリケーションアーキテクチャを直接構築し、それに基づいてコードを記述して設計をモデル化する人々を正確に引き付ける必要があるので、すぐにこれを行うことができるかどうかを判断できます。 誰かが間違えたとしても、すぐに修正できるようになります。
DDDの経験の欠如。 私は、DDDは主にプロジェクトチーム、開発者の意識の変化であり、アナリストと同様に分析に関与し、これがどのように実装されるかをより詳しく見る必要があると言わなければなりません。 開発と分析に関与する必要があるプロジェクトマネージャーも同様です。 まあ、DDDの基本部分であるモデル駆動設計自体は、コードで思いついたことを実装しようとしているため、何らかの種類の内訳が必要です-常にどこかでスリップし、ここでデータセットを取得し、そこで何かをしたいのですまだ。
さて、多くの技術的な問題があります。 すべての問題は、モデル駆動設計に関連しています。 まず第一に、これらは何らかの方法でデータを保存するための悪いツールです。明らかに、オブジェクト指向言語では何らかの手段を使用する必要があります。 通常、企業システムのデータはリレーショナルデータベースに保存されます。 これにより、リレーショナルデータベースからオブジェクトモデルへのコンバータを選択する必要があります。 Hibernateや他のORMなど、このための多くの産業用ツールもありますが、それらにはすべて問題があります。 それらは使用するのが難しく、理想からはほど遠いので、何らかの種類のデータベースが存在するという事実を無視できます。多くの場合、それはDDDを放棄する必要があるほど重要であり、そうでなければシステムはありません。悪いツールと戦っている間。 また、他の分野や技術、たとえば分散システムでは、DDDにさらに問題があります。モデルをコードに直接マッピングすると、まったく異なるモデルがコードに忍び込み始めます：分散システム間の相互作用のモデル、相互作用モデルデータベースを使用することは、完全に不要なプログラムモデルにすぎません。
これはすべて、DDDの使用が不可能または望ましくない、または非常に高価になるという事実につながる可能性があります。
それで、DDDの簡単な紹介をしたいと思います。 そして、あなたは本当にモデルベースの設計ツールを持っているので、このアプローチを試してみます。

質問：

質問： OOPアプローチとDDDの違いは何ですか？
回答： OOPアプローチは、モデルを構築するために私たちを呼び出しません; OOPアプローチは、データと動作の組み合わせであり、これはサブジェクトエリアに関連しない場合があります。 私が引用したデータセット、datariversはOOPアプローチでもあります。オブジェクトが異なり、動作が異なるだけで、それらは私たちが解決しようとしている問題とは関係なく、技術的な理由によって引き起こされます。 また、DDDは、現実世界での配置方法によって、特定の方法でこれらのオブジェクトを構築することを強制する一連のアプローチとビューです。 同時に、DDDは、なんらかの方法でモデルを構築しないことを推奨します。その後、モデルをOOPに反映し、すべての概念を明示的に、そして私たちが話しているものに近づけます。 DDDで作業していることを示す良い例は、フレーズを言ったり、タスクを設定したり、コード、コメントでまったく同じように見えるときです-それはまさにコードが言うことです。 「従業員の給与を計算する」と表示されている場合、コードは「従業員の給与を計算する」とも表示します。 「従業員の給与が就業日数*給与+休暇日数*平均年間給与」であると書かれている場合、まったく同じ用語で、それはもちろん、言語にとってより便利な場合は英語でも当てはまります悪い-それは書かれるべきです。 また、「select from db order by ... group by ...」と記述している場合、これはすでにモデル駆動設計から遠ざかり、モデルが実装しているものと一致しなくなったことを示しています。

質問：これが技術的なエンティティ（シート、データベース、その他）からビジネスエンティティへの移行であることを正しく理解できますか？
: , , .

: . ?
: . . Facebook, , – . , , -, , . , . . , , , .

: overdraft, ?
: , DDD . , , ( ..). , , , , . . , , , , DDD, . , , – , .

: . , , .
: . - . , , . , DDD . , , . , , , , 10 , – -, . , , -, – , , . , : - «»? , , , – , , . « » — , – . , ! , , , , .