DDDと責務、Architecture..①DDDの概要を知る

DDDとちゃんと仲良くなりたい

"DDDとそのアーキテクチャの概要"と題して、書いていこうと思う。
一回では書き切ることができないので分けて書いていくこととして、今回は概要編。

というのも、私がエンジニアになって始めて出会ったとき本当に難しくて、(今もだけど)
メンターとして教えるとなった時もアーキテクチャに関しては自分の理解が浅く難しく...泣

だったので、自分の整理のために。

違うなーと思うところがあればコメントください👀

今まで見てきてわかりやすかったもの達も、最後の参考文献に記載してるので
もし悩んでる方がいたら参考にしてください!

概要: What is DDD　[Domain-driven design (ドメイン駆動設計)]

What is Domain Driven Design?

1. Focus on the core complexity and opportunity in the domain
2. Explore models in a collaboration of domain experts and software experts
3. Write software that expresses those models explicitly
4. Speak ubiquitous language within a bounded context

• Eric Evansが提唱した設計手法.(理論、考え方、概念)
• 2003年 Domain-driven design 出版
• DDDは、一言で言えばビジネスドメインに焦点を当てたソフトウェア設計手法。

  • 複雑なビジネスドメインを扱うためのアプローチとして登場した。
    ビジネスルールやプロセスを表現する豊かなモデルを構築する。

  • ビジネスの核心部分(ドメイン)を明確にし、その理解をモデル化することで、
    ソフトウェアの設計と実装に反映させます。
    →開発するときにビジネスのドメインに関する知識を重視し、
    その知識をもとにソフトウェアの設計や実装を行うもの。

    DDD本ではドメインを"知識、影響力、活動の一領域"と定義していて、
    ドメイン層がユーザの業務に直接的に関わる部分になるため、
    ここを正しく構築できるかどうかが大事だと記載している。

補足: 言葉の意味(設計手法/デザインパターン/アーキテクチャ)

私は最初この言葉たちをわかってなくて,説明できなくて困ったので簡潔に書きました...!

言葉の意味(設計手法/デザインパターン/アーキテクチャ)

• 設計手法（Design Methodology）：
  ソフトウェアの設計における手法やプロセス。

• アーキテクチャ（Architecture）：
  ソフトウェアシステムの構造や構成要素、およびそれらの相互作用を定義する設計上の
  考え方や枠組み。システム全体の構造や設計に関わる概念や原則を指す。
  ex.) レイヤードアーキテクチャ、ヘキサゴナルアーキテクチャ、オニオンアーキテクチャ、クリーンアーキテクチャ

• デザインパターン（Design Patterns）:
  ソフトウェア設計における特定の問題や課題に対する解決策やベストプラクティスを
  提供する再利用可能なテンプレート。
  ex.) Singletonパターン、Factoryパターン、Observerパターン

DDDでよく出てくる用語

DDDでよく出てくる用語

用語	意味	簡単に言えば...
ドメイン	問題領域や業務領域のこと。 ソフトウェアが解決しようとしている現実世界の課題や要件。	解決しようとする問題のこと。 ex. 会計ソフトを作るならば、 ドメインは会計業務
責務	特定のドメインモデルやコンポーネントが持つ具体的な役割や機能、責任	役割!
ドメイン エキスパート	ドメインの専門家。 特定のドメインにおける知識や経験が豊富な人。	業務(ドメイン)について誰より知ってる人
ユビキタス言語	ドメインエキスパートと開発者がチームで共有する言語。	みんなの共通認識としての言語、表現
コンテキスト	特定の業務や問題領域における状況や状態のこと。 ドメインの一部分。	ドメインは全体のビジネス領域を示し、コンテキストはその中の特定の部分を示す
コンテキスト境界	コンテキスト間の境界。 ドメイン内の異なる部分や業務領域を区別するための境界。	ドメインモデルを適用できるコンテキストの範囲のこと
集約	一つ以上のエンティティや値オブジェクトをまとめた複合オブジェクト。 トランザクションの整合性を保つ単位。
凝集度	クラス内の責務、データ、振る舞いの関連の強さ。	"高い凝集度"→ 1つの目的に特化し、関連する要素がまとまっていること.
結合度	クラス間やモジュール間の相互依存度。	"低い結合度"→独立性が高く、変更が容易な設計
共有カーネル	マイクロサービスアーキテクチャにおいて、複数のマイクロサービス間で共有される共通の部分
課題ドリブン	問題解決に焦点を当てたアプローチ。要件や設計を問題の解決に対して重視する方法論。	問題解決に焦点を当てたアプローチ

3層アーキテクチャの課題とDDDによる解決策

DDDが出てくる前までは、三層アーキテクチャが主流であった。そこにも課題点があり...

• 3層アーキテクチャの課題点:

  • ビジネスロジックの肥大化:
    アプリケーション層におけるビジネスロジックの集中が、
    コードの複雑性や保守性の問題を引き起こす可能性がある。
  • ビジネスルールの分散:
    ビジネスルールがアプリケーション層やデータアクセス層に散在している場合、
    ビジネスロジックの理解や変更が難しくなる。

• DDDにより解決しようとしたこと:

  • ビジネスドメインの重視:
    ビジネスドメインを中心に据え、
    ビジネスロジックをドメインモデルとして明確化することで、肥大化や混乱を防ぐ。
  • 豊かなドメインモデルの構築:
    ドメインエキスパートとの協力により、
    ビジネスルールやプロセスを正確に表現し、アプリケーション全体で共有する。
  • コンテキスト境界の定義:
    ドメインモデルを境界付けし、各コンテキスト内でのみ有効なビジネスルールや
    データを管理することで、データベーススキーマの変更に対する影響を最小限に抑える。

ビジネスドメイン?モデル?ドメイン?

モデルって何？というところから。

model:A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain
-- DDD Reference

問題解決のために、物事の特定の側面を抽象化したもの、と定義されている。
DDD の文脈で頻出する 2 種類のモデルがあり、それが以下2つ。

• ドメインモデル:
  ドメインの問題を解決するためのモデル
• データモデル:
  データの永続化方法を決める (永続化方法の効率化という問題解決 を行う) ためのモデル

そして、ドメインってなんなの？

A sphere of knowledge, influence, or activity.
The subject area to which the user applies a program is the domain of the software.
-- DDD Reference

知識、影響力、または活動の領域。
ユーザーがプログラムを適用する対象エリアは、ソフトウェアのドメインである。
と定義されている。

アプリケーションの対象となる"業務領域"がドメインだ。
これについてはまたのちに詳しく書く。

DDDの目的ってなんだ

ここまで色々書いたけど、目的は...

この"モデル(ドメインモデル)=ビジネスの核心部分"を正確に反映し、
モデリングによってソフトウェアの価値を高める、ソフトウェアの品質を上げる

ことだ。

良いモデルとは?"モデリングによってソフトウェアの価値を高める?"

DDDでの記載した目的を踏まえると、以下の点が大事と言える。

• "問題を解決できるモデル"であること

  • モデルは"問題解決のために、物事の特定の側面を抽象化したもの"であるから。

• ビジネスドメインの正確な反映

  • ドメインエキスパートとの協力とユビキタス言語によって実現し、
    モデルに落とし込むこと。

• 柔軟性と拡張性

  • 得られた発見をモデルに還元できていること

ドメイン駆動設計 モデリング/実装ガイド

モデルが良くなければ、実装がよくても問題は解決できないし、
モデルが良くても、それをソフトウェアで実現できなければ、DDDの目的は果たせないため、

1. ドメインについての理解を深め、モデルを継続的に改善する
2. モデルを継続的にソフトウェアに反映する

この2点が大切だ。

ユビキタス言語（Ubiquitous Language）

ユビキタス言語は、DDDの中心的な概念の一つで、システム開発において
「開発者、クライアントなどプロジェクトに関わる人全体で作り上げ共有する言語」
のことを指す。

簡単にいうと、ドメインモデルに基づく言語で、全員の共通認識を作るツール...と言える。
ドメインの複雑な概念を正確に共有することが可能になる。ということは、
ドメインモデルがビジネスルールやプロセスを正確に反映し、ソフトウェアの品質が向上する。

ドメインとコンテキストの概念

最初に結論だけ書くと以下のようになる。

• ドメイン：特定のビジネスや活動の領域
• コンテキスト：ドメイン内で一貫した意味を持つ境界

-> ドメインは全体のビジネス領域を示し、コンテキストはその中の特定の部分を示す。

これをオンラインショッピングサイトを例として使って
ドメインとコンテキストの概念の説明をすると...

【　ドメイン（Domain） 】
ドメインは、特定のビジネスや活動の領域を指すと記載した。
オンラインショッピングサイトの場合、
ドメインは 「オンラインショッピング業務」全体を指す。

このドメインには、
商品の管理、注文の処理、顧客の管理、支払いの処理...etc
サイト運営に関わるすべての業務が含まれる。
このそれぞれを"コンテキスト"と読んでいる。

【　コンテキスト（Context） 】
コンテキストは、ドメインの中で特定の部分を指し、
その部分での用語やモデルが一貫して理解される境界 (コンテキスト境界)を表す。

オンラインショッピングサイトのドメインには、いくつかのコンテキストが存在する。

ex.

• 商品管理コンテキスト：
  責務：商品の情報を管理する。
  要素：商品名、価格、在庫数、商品説明など。
  例：新しい商品を追加する、商品の価格を変更する、在庫数を更新する。

• 注文処理コンテキスト：
  責務：注文の作成と管理。
  要素：注文ID、注文日、注文した商品のリスト、支払い情報、出荷情報など。
  例：新しい注文を作成する、注文のステータスを更新する、注文をキャンセルする。

:
:

ドメインモデルを表現するもの

Entity, ValueObject(VO) などがあるが、ここも書くと長々となってしまうので、

次回は"それぞれの責務と実装"について詳しくかいていきたいと思う。

参考

本

• わかる！ドメイン駆動設計 ～もちこちゃんの大冒険～【C91新刊】*とても優ｼｲ一番初めに良い

• ドメイン駆動設計 モデリング/実装ガイド *個人的にちょうどいい優しさ

• ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本

• 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

• エリック・エヴァンスのドメイン駆動設計: ソフトウェアの核心にある複雑さに立ち向かう*ﾑｽﾞｶｼｲ

→ エヴァンス本解説ページ：https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html

DDD公式サイト

• Domain Language --Tackling Complexity in the Heart of Software
• DDD Reference

動画、講座、HP

• The Onion Architecture : part 1~4

• LinkedIn: Better apps with domain-driven design - Software Architecture: Domain-Driven Design Video Tutorial | LinkedIn Learning, formerly Lynda.com

Youtube 個人的にわかりやすかったチャンネル

• 実践クリーンアーキテクチャ 音ズレ修正Ver.【プログラミング】

• https://www.youtube.com/watch?v=80NeuPXs2J0

• https://www.youtube.com/watch?v=BvzjpAe3d4g