コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

利用者:Br3kyokyo/sandbox/ドメイン駆動設計2

ソフトウェア開発工程
中心となる活動
パラダイムとモデル
ソフトウェア開発方法論とフレームワーク
開発支援
プラクティス
プログラミングツール
標準と機関
用語集

ドメイン駆動設計（ドメインくどうせっけい、英語: domain-driven design、DDD）は主要なソフトウェア設計手法の一つであり[1]、ドメインエキスパートの言葉に基づき、ドメインにおけるプロセスやルールをよく表現したドメインモデルを構築し、それに基づいてソフトウェア開発を行うことに主眼を置くものである[2][3][4]。

DDDでは、事業領域内において同じ言葉を使うことによって、ある事業におけるドメインエキスパートとエンジニア間での事業活動に対する共通理解を形成する。

DDDは以下のような目的に基づく。

  • プロジェクトにおける主な焦点を中核の業務領域と業務ロジックのレイヤーに置くこと
  • 複雑な設計をドメインモデルで表現すること
  • 技術者とドメインエキスパートの間にクリエイティブな協働関係を構築し、特定のドメイン問題を扱う概念的なモデルを継続的に洗練させること[5]

DDDという名称は、エリック・エヴァンス（英語版）による著書の中で初めて提唱されたものである[6]。

エリック・エヴァンスの「ドメイン駆動設計」とヴォーン・ヴァーノンの「実践ドメイン駆動設計」の二つの書籍を合わせて、古典DDDと呼ばれることがある[要出典]。

概要

[編集]

DDDは、多くの高水準な概念と実践を明確に示している[6]。

もっとも重要なものは、ソフトウェアにおける「ドメイン」であり、これはユーザがプログラムを適用する対象領域を指す。戦術的設計の一つであるドメインモデルパターンにおいては、ソフトウェアの開発者は「ドメインモデル」を構築する。これは特定のドメインのある側面を表現し、ドメインにおける問題を解決するために用いることができるような抽象化のシステムである。

DDDは大きく戦術的設計と戦略的設計に分けられる[誰?]。

戦略的設計では、主に、同じ言葉、区切られた文脈という概念の導入と、事業活動をその性質によって複数の業務領域に分類することを行う。事業活動は、中核の業務領域（コアドメイン）、一般的な業務領域（ジェネリック・サブドメイン）、補完的な業務領域（サブドメイン）に分類される[7]。

戦術的設計では、DDDにおける戦略を達成するために、具体的にどのように業務ロジックを表現し、ソフトウェアを実装するかという点についての議論を行う[7]。業務ロジックの表現方法としては、トランザクションスクリプト、アクティブレコード、ドメインモデル、イベント履歴式のドメインモデルなどが挙げられる[7]。

歴史

[編集]

戦略的設計

[編集]

言葉の意味と文脈

[編集]

DDDにおいては、ドメインエキスパートと技術者間で同じ言葉を用いることによって、業務に対する共通理解を形成する[7][8]。ただし、同じ事業領域内においても、背景が異なれば異なった意味を持つ言葉が存在する。この曖昧さを解消するために、DDDでは区切られた文脈という概念を導入する[7]。

同じ言葉（ユビキタス言語）

[編集]

同じ言葉、あるいはユビキタス言語（英語: Ubiquitous language）とは、同じ言葉を使うことでドメインエキスパートと技術者間の効率的な意思伝達を促す、DDDにおける戦略的手法のことである。区切られた文脈内において、同じ言葉は同じ意味を持つ。DDDでは、技術者がドメインエキスパートと協力しながら同じ言葉を育て、特定のドメイン問題を扱うモデルの継続的な洗練を目指す[7]。

ソフトウェアコード（e.g. クラス名、クラスメソッド、クラス変数）における言葉や構造はビジネスドメインに一致する。例えば、ソフトウェアがローン申請(loan application)を処理する場合、ソフトウェアは「loan application」「customer」といった名前のクラスや「accept offer」「withdraw」といったメソッドを持つことが考えられる。

区切られた文脈（境界づけられたコンテキスト）

[編集]

区切られた文脈、あるいは境界づけられたコンテキスト（英語: Bounded context）とは、同じ言葉に同じ意味を適用できる範囲のことである。区切られた文脈は、ソフトウェア設計の観点で、ソフトウェア技術者が決定する[7]。

マーティン・ファウラーによれば、ドメインが大きくなるにしたがって、単一の統一されたモデルを構築することは難しくなる[9]。これは、事業領域において、同じ言葉でも文脈によって異なる意味を持つ場合が出てくるためである[注釈 1]。

DDDではシステム全体が単一の統一されたモデルを持つという考え方に反対し、システムを複数の区切られた文脈に分けることを推奨する。区切られた文脈はそれぞれが自らのモデルを持つ[11]。

計算機科学における難題は二つしかない。それはキャッシュの無効化と、命名である。ー フィル・カールトン[12]

区切られた文脈は言語学における「意味論的な領域（英語版）」に基づいているとされる。意味論的な領域とは、同じ言葉が同じ意味で使われる範囲のことを指し、例えば「トマト」が植物学的な文脈では「果実」である一方で、法的[注釈 2]な文脈では「野菜」であるようなことが挙げられる[7]。

業務領域の分類

[編集]

DDDにおいて、ソフトウェアは中核の業務領域と、一般的な業務領域、補完的な業務領域に分けられる。DDDにおける重要かつ主要な目的の一つは、戦力を中核の業務領域に集中させることであるとされる[13]。

あるソフトウェアにおいて中核の業務領域であっても、他のソフトウェアにとっては一般的な業務領域であることはあり得る。

中核の業務領域

[編集]

中核の業務領域（英語: Core subdomain）は、プロジェクトのコアとなる複雑で重要なロジックを含む部分である。このような業務領域におけるドメインロジックの表現には、ドメインモデルなどの複雑な業務ロジックを扱うための戦術的設計を選択することが考えられる。事業において戦略上強みとなる部分であり、頻繁な変更が考えられる[7]。

一般的な業務領域

[編集]

一般的な業務領域（英語: Generic subdomain）はどのソフトウェアにおいても基本的にアプローチが変わらないような部分であり、したがって外部のソフトウェアやライブラリを活用することが考えられるとされる[7]。例としては認証処理、暗号化などが挙げられる。

補完的な業務領域

[編集]

補完的な業務領域（英語: Supporting subdomain）は、事業活動を支えるものの、競争優位を生み出さない部分である。補完的な業務領域のロジックは単純かつ変更が少ないとされ、トランザクションスクリプトやアクティブレコードなどの簡易な業務ロジックの表現方法を用いることが適している[7]。

戦術的設計

[編集]

戦術的設計では、具体的にどのようにソフトウェアを実装するかという問題を取り扱う。以下はDDDで用いられる主要な技術方式である。

業務ロジックの表現方法

[編集]

ヴラド・コノノフは、シンプルな業務ロジックに対する実装方法としてトランザクションスクリプトとアクティブレコード、複雑な業務ロジックに対するデザインパターンとしてドメインモデル、それを時系列に拡張したものとしてイベント履歴型のドメインモデルを挙げている[7]。

増田享によれば、トランザクションスクリプトはユースケースと呼ぶことができる[14]。これはトランザクションスクリプトがユースケースの最も単純な実装であるためである[要出典]。

トランザクションスクリプト

[編集]

トランザクションスクリプト（英語: Transaction Script）は手続き的な業務ロジックの実装方法であり、プレゼンテーション層から渡されるリクエストを処理する一連の流れの中で業務ロジックを表現する[7][15]。トランザクションスクリプトは、ユースケースとドメインロジックを共に表現する[16]。

アクティブレコードパターン

[編集]

アクティブレコード（英語: Active Record）はドメインモデルの一種であり、モデルがDBのテーブルあるいはビューと一対一に対応する。アクティブレコードのオブジェクトはDBにおけるテーブルのレコードを表現し、レコードを表現するオブジェクト自身がデータアクセス処理を行う[7][17]。

アクティブレコードを用いるメリットとしては、構造がシンプルで、データベース操作が直感的になるということがある。アクティブレコードを用いた場合でも、業務ロジックはトランザクションスクリプトとして記述する。この場合、コードはDBを直接操作するのではなく、アクティブレコードオブジェクトを操作する[7][18][19]。

アクティブレコードのデメリットとしては、テーブルとモデルが一対一に対応していることから、モデルがデータベースの構造に依存することと、ドメインモデルとしての柔軟性を欠くという点が挙げられる[19]。

アクティブレコードの目的は、DB操作の最適化であるとされる[7]。

ドメインモデルパターン

[編集]

ドメインモデル（英語: Domain Model）は、業務ロジックとデータの両方を一体化させた、事業活動を表現するオブジェクトモデルである[20]。ドメインモデルは他の層の知識に依存せず業務知識を表現することが望ましいとされ、その点で後述のポートとアダプタパターンと相性が良い[7]。

ドメインモデルパターンのメリットとしては、ドメインモデルがインフラストラクチャ層の知識に依存することを回避するため、純粋に業務ロジックを表現できることが挙げられる。

典型的なドメインモデルは集約とそれを構成するエンティティ、値オブジェクト、ドメインサービスによって表現される。集約はドメインモデルの永続化におけるトランザクションの単位であり、業務ロジックはエンティティや値オブジェクトのフィールド、あるいはメソッドとして定義されるのに加え、それらに定義することが不自然であったり、ロジックが集約を跨いで存在する場合、これはドメインサービスによって表現される[7]。

ドメインモデルが持つべき情報がドメインモデルの外に書かれており、業務知識が漏れ出している状態を、「ドメインモデル貧血症」と呼ぶことがある[21]。

イベント履歴式のドメインモデル

[編集]

イベント履歴式のドメインモデルでは、集約の状態変化をドメインイベントで表現する。これはイベントソーシングという。ドメインモデルパターンでは集約の状態自体を永続化するのに対し、イベント履歴式のドメインモデルでは集約の状態の変化を表すドメインイベントを永続化する[7]。

このパターンにおいては過去のある時点においての状態を得ることができるというメリットがある一方で、現在の状態を再現するために計算が必要になるというデメリットがある。これについては、テーブルが更新されるたびに最新の状態を投影したビューを更新し、CQRSパターンを用いて読み込みモデルからはこちらを参照することで対応できるとされる[7][22]。

アーキテクチャ方式

[編集]

階層化アーキテクチャ

[編集]

ソフトウェアの階層化は情報技術において一般的な考え方の一つである[要出典]。例えば、コンピュータネットワークの分野においては、OSI参照モデルが階層化アーキテクチャとして挙げられる。

アプリケーションレベルのソフトウェアアーキテクチャにおいては、以下に示すようないくつかのアーキテクチャパターンが知られている。

レイヤードアーキテクチャ
[編集]

古典的な三層レイヤードアーキテクチャでは、技術的な関心に基づいて、アプリケーションをプレゼンテーション層、ドメインロジック層、データアクセス層の三層に分ける[7][23]。

ポートとアダプタ方式
[編集]
→詳細は「ポートとアダプタ」を参照
クリーンアーキテクチャの概念図
クリーンアーキテクチャの概念図

ポートとアダプタ方式では、依存性の逆転を行うことによって、古典的レイヤードアーキテクチャにおけるドメインロジック層がデータアクセス層に依存することを回避する。この方式に基づいたアーキテクチャモデルとしては、オニオンアーキテクチャ、クリーンアーキテクチャ、ヘキサゴナルアーキテクチャ（英語版）が知られる[7]。

これらのアーキテクチャは複数の層を持つ円として表現され、内層は外層の知識に依存しない。アーキテクチャの中心にはドメインロジックが存在し、中心のドメインロジックが他の何にも依存しないという性質から、これらのアーキテクチャを用いることによって、ドメインモデルが具体的なインフラストラクチャ層の知識に依存することを回避することができる[7]。

クリーンアーキテクチャを提唱したロバート・マーチン（英語版）によれば、奥に行くほどソフトウェアのレベルは高くなり、外層はメカニズムで、内層はポリシーであるとされる[24]。

依存関係逆転の原則

[編集]
→詳細は「依存性逆転の原則」を参照

CQRS（コマンドクエリ責任分離）

[編集]
→詳細は「コマンドクエリ責任分離」を参照

ドメインモデルの構成要素

[編集]

典型的なドメインモデルは集約とそれを構成するエンティティ、値オブジェクトに加え、ドメインサービス、ドメインイベントといった要素からなる。

集約

[編集]

集約は複数のエンティティからなり、永続化においてデータの一貫性が必要とされるトランザクションの単位である。集約においてルートとなるエンティティが永続化におけるインターフェースとなる[7]。例えば、BookとStockというエンティティがあり、これらがBook集約を形成しているとすると、ここでのルートはBookエンティティである。

集約の永続化には、リポジトリパターンが用いられることが一般的である。ここでのリポジトリは集約の入出力の単位のインターフェースとして用いられる[25][26]。典型的なパターンでは、インフラストラクチャ層がドメインモデルのポートを実装し、ユースケースがリポジトリを用いて集約の出し入れを行う。

エンティティ

[編集]

エンティティは識別子によって同一性が識別され、エンティティや値オブジェクトによって状態が表現されるミュータブルなオブジェクトである。例えば、ほとんどの航空会社はすべてのフライトにおいて席に対して一意の数字を割り当てている。これは席の識別子である。

値オブジェクト

[編集]

一方で値オブジェクトは属性の組み合わせによって同一性が識別されるイミュータブルなオブジェクトである[7][注釈 3]。例えば、ある人が名刺を交換する際を例に挙げると、この時名刺を交換する人は名刺の内容（属性）のみに関心があり、名刺一枚一枚を個別に扱うことはない。

ドメインサービス

[編集]

ドメインサービスは状態を持たないオブジェクトであり、複数の集約に跨る処理や、エンティティや値オブジェクトに実装することが不自然な業務ロジックの実装に用いられる[7]。

ファクトリ

[編集]

集約など、ドメインモデルを構成する要素の生成手順が複雑な場合、ファクトリを導入してオブジェクトの生成処理をカプセル化する[27]。

実装の選択

[編集]

ドメインモデルパターンでは、開発者がドメインモデルを純粋で有用な構造として維持するためには、通常大量の分離とカプセル化を行う必要がある一方で、保守性などの利点を提供する。このことから、Microsoftは、ドメインに対する共通理解を構築することで明確な利点のある複雑な業務領域にのみドメインモデルパターンを導入することを推奨している[3][注釈 4]。

実際のところ、ユースケースの実装としてはアクティブレコードなどを実装したORMを用いたトランザクションスクリプトで事足りることは多い。抽象化とパフォーマンスを両立することは容易ではなく、実際のところドメインモデルを抽象化せずに、トランザクションスクリプトで全ての処理を記述した方が開発上のコストパフォーマンスに優れている場合がある。これは、抽象化はパフォーマンス上の問題を抱えやすく、ドメインモデルを抽象化する際においても、パフォーマンスを向上させるためにはその実装を知らなくてはならないことによる（漏れのある抽象化の法則（英語版））。そのため、即応性が必要とされる処理などにおいてはトランザクションスクリプトが適していることがある[要出典]。

関連項目

[編集]
  • コードベース - ドメイン駆動設計を用いることによって、業務ロジックのコードベースを効率的に管理することができる。

他の概念との関係

[編集]
オブジェクト指向分析設計
ドメイン駆動設計の考え方は、理論上、オブジェクト指向の手法に制約されるものではない。実際、ドメイン駆動設計では、オブジェクト指向の技法が実現する強みを活かそうとしている。
モデル駆動工学（MDE）
モデル駆動型アーキテクチャ（MDA）
MDAの考え方は、ドメイン駆動設計と両立するが、二つの概念の意図するところは多少異なっている。MDAは、ドメインモデルをよりよく定義する方法よりも、技術の異なるプラットフォームに対してモデルをコードに変換する方法の方に関心がある。
POJOとPOCO
POJOとPOCOは実装上の考え方であり、それぞれJavaと.NET Frameworkに固有のものである。しかし、POJOとPOCOという用語が現れたことは、二つのプラットフォームのいずれかにおいて、特定のテクノロジの要求に応じてではなく、純粋に対応するドメインの概念のビジネス上の振る舞いを実現するためにドメインオブジェクトが定義されるべきである、という考え方が広まりつつあることを示している。
Naked Objectsパターン
このパターンは、次の二つの仮定に基づいている[28]。
  1. 良質なドメインモデルがあれば、ユーザインターフェイスは、単純にドメインモデルを反映したものになる。
  2. ドメインモデルを直接反映したユーザインターフェイスが必要であれば、より良いドメインモデルの設計を余儀なくされる。
ドメイン固有言語（DSL）
ドメイン駆動設計は、必ずしもDSLを必要としないが、DSLを定義し、domain-specific multimodeling（英語版）のような手法の実践を助ける。
アスペクト指向プログラミング（AOP）
AOPを用いると、技術的な関心（セキュリティ、トランザクション管理、ロギング）をドメインモデルから簡単にくくりだすことができ、純粋にビジネスロジックに焦点をおいたドメインモデルの設計と実装を容易にする。

ドメイン駆動設計をサポートするソフトウェアツール

[編集]

ドメイン駆動開発の実践は、特定のソフトウェアツールやフレームワークに依存したものではない。しかし、多数のオープンソースツールとフレームワークがEvansの書籍で推奨しているパターンや、ドメイン駆動開発の方法をサポートしている。以下のようなものがある。

  • Castle Windsor/MicroKernel[29]：マイクロソフトの.NET Framework向けの制御の反転/依存性の注入コンテナであり、サービスとリポジトリ、ファクトリーを利用者に提供する。
  • Cosmos[30]：ドメイン駆動設計の、中でもAOPの実践をサポートした、アプリケーションフレームワーク。
  • DataObjects.Net：データベースアプリケーションのフレームワーク/開発環境であり、オブジェクト関係マッピングとドメイン駆動開発をサポートしている。
  • Domdrides[31]：ドメイン駆動設計をJavaで実現する際に有用なライブラリ。
  • ECO：CapableObjects社[32]によるUML図からのデータベース、コード、状態マシンの生成を行うフレームワーク。
  • Flow[33]：PHPのアプリケーションフレームワークで、ドメイン駆動開発を中心においている。良質なドメインモデルの形成を促し、またリポジトリ、エンティティ、値オブジェクトをサポートする。また依存性の注入、AOPのフレームワークを提供している。
  • Habanero.NET（Habanero）：オープンソースのドメイン駆動開発の原則を用いてエンタプライズアプリケーションを開発するためのエンタプライズアプリケーションフレームワークで、.NET Framework上に実現されている。
  • ManyDesigns_Portofino：ManyDesigns Portofinoはオープンソースのモデル駆動型のWebアプリケーションフレームワークで、高い生産性とメンテナンス性を目標にしている。CRUDフォーム、関係、ワークフロー管理、ダッシュボード、パンくずリスト、検索、シングルサインオン、権限、レポートなどを提供する。
  • NakedObjectsFramework[34]、Apache Isis[35]：naked objectsパターンを実現しており、依存性の注入をサポートしている。またドメイン駆動設計におけるリポジトリ、ファクトリー、サービスの概念を、再利用可能な形で実装している。
  • NReco[36]：軽量なオープンソースの.NET向けドメイン固有のMDDを行うフレームワークである。JQuery、Open NIC.NET、OGNL、Log4Net、Lucene.NET、SemWebなどと結合されている。
  • OpenMDX：Jakarta EE、.NETをサポートするオープンソースのJava向けMDAフレームワークである。OpenMDXは典型的なMDAフレームワークとは異なり、「実際のシステムの振る舞いを直接操作するためにモデルを使用する」。
  • OpenXava：はJPAのエンティティからAjaxアプリケーションを生成する。実行可能なアプリケーションを作成するために、ドメインクラスを記述するだけでよい。
  • Roma Meta Framework[37]：ドメイン駆動開発を中心においたフレームワークで、新しい全体的な方法により、設計者・開発者がGUI、国際化、永続化など、何もかもPOJOとして見えるようにする。
  • Sculptor[38]:ドメイン駆動開発の用語を用いるコード生成フレームワーク。
  • Sculpture - Model Your Life[39]：オープンソースのモデル駆動開発のコード生成ツールの中で、Sculpture は最も強力なものの一つである。単純なCRUDアプリケーションから、複雑な大規模アプリケーションまで、SculptureはNHibernate、Entity Framework、WCF、CSLA、Silverlight、WPF、ASP.NET MVC などの一般的なフレームワークのための型をあらかじめ用意している。
  • Strandz[40]：ドメイン駆動のフレームワークで、アプリケーションのUI層と、ドメイン層双方の実装に非依存である。プログラマーは、特殊なクラスを用いてアプリケーションのワイヤモデルを記述する。
  • TrueView for .NET[41]：モデル駆動開発とnaked objectsをサポートした簡単に使用できるフレームワークで、これからモデル駆動開発を開始しようというチームに向いている。
  • ASP.NET Boilerplate[42]：ドメイン駆動開発のWebアプリケーション作成フレームワークで、N層レイアのアプリケーション開発が可能となっている。名称からも分かるようにマイクロソフトの.NET Frameworkの技術の上に構築されている。

脚注

[編集]

注釈

[編集]
  1. ^ 例えば「見込み客」という言葉は、ある文脈においては「自社の製品に興味を持った」という意味であり、他のある文脈によっては「営業プロセスにおいて取り組むべき対象」という意味で用いられ得る[10]
  2. ^ アメリカ法
  3. ^ 同じ属性の組み合わせを持つオブジェクトは同じものとして扱われる。例えば、同じカラーコード（RGB）を持つ色は同じ色である。
  4. ^ 原文で導入を勧めているのは「Domain Driven Desing」だが、原文ではDDDを「ドメインエキスパートの言葉で表現されるドメインモデルを定義する」ものとしているため、ドメインモデルに対しての記述であると考えられる。

出典

[編集]
  1. ^ Millet, Scott; Tune, Nick (2015). Patterns, Principles, and Practices of Domain-Driven Design. Indianapolis: Wrox. ISBN 978-1-118-71470-6 
  2. ^ “bliki: Domain Driven Design”. martinfowler.com. 2024年9月4日閲覧。
  3. ^ a b Archiveddocs (2010年1月14日). “Chapter 3: Architectural Patterns and Styles” (英語). learn.microsoft.com. 2024年9月7日閲覧。
  4. ^ Vernon, Vaughn (2013). Implementing Domain-Driven Design. Upper Sadle River, NJ: Addison-Wesley. p. 3. ISBN 978-0-321-83457-7 
  5. ^ Domain-Driven Design Europe (2019-12-21), What is DDD - Eric Evans - DDD Europe 2019, https://www.youtube.com/watch?v=pMuiVlnGqjk&t=739s 2024年9月7日閲覧。 
  6. ^ a b Evans, Eric (2004). Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison-Wesley. ISBN 978-032-112521-7. http://dddcommunity.org/book/evans_2003/ 2012年8月12日閲覧。 
  7. ^ a b c d e f g h i j k l m n o p q r s t u v w x y z Vlad Khononov 著、増田亨・綿引琢磨 訳『ドメイン駆動設計をはじめよう』株式会社オライリー・ジャパン、2024年7月18日、xx, 44頁。 
  8. ^ “bliki: Ubiquitous Language”. martinfowler.com. 2024年8月27日閲覧。
  9. ^ “bliki: Bounded Context”. martinfowler.com. 2024年9月4日閲覧。
  10. ^ 引用エラー: 無効な <ref> タグです。「:082」という名前の注釈に対するテキストが指定されていません
  11. ^ martinekuan. “Using tactical DDD to design microservices - Azure Architecture Center” (英語). learn.microsoft.com. 2024年9月7日閲覧。
  12. ^ “CQRS – Simple architecture | Kariera Future Processing” (ポーランド語). kariera.future-processing.pl (2015年4月10日). 2024年9月3日閲覧。
  13. ^ digitalsoul (2011年4月10日). “戦略的設計入門”. Digital Romanticism. 2024年8月27日閲覧。
  14. ^ 増田享 (2024-01-14 ·). “データの入れ物(データクラス)をエンティティや集約と呼び、テーブルに自動マッピングする仕組みをリポジトリと呼び、トランザクションスクリプトをユースケースと呼ぶ。 こうやって呼び方を変えるだけで、誰でも簡単にドメイン駆動設計を始められる。”. 𝐗 (Twitter). 2024年9月29日閲覧。
  15. ^ “Transaction Script”. martinfowler.com. 2024年9月4日閲覧。
  16. ^ “「サービスクラス」は 3 種類ある - 完全に理解した.com” (英語). 「サービスクラス」は 3 種類ある - 完全に理解した.com. 2024年10月1日閲覧。
  17. ^ “Active Record”. martinfowler.com. 2024年9月6日閲覧。
  18. ^ “Active Recordとは？その基礎と重要性を解説 | 株式会社一創”. www.issoh.co.jp (2024年7月3日). 2024年9月5日閲覧。
  19. ^ a b “Rails/Laravel使いに送るドメインモデル~アクティブレコードの功罪~”. Qiita (2020年2月9日). 2024年9月6日閲覧。
  20. ^ “Domain Model”. martinfowler.com. 2024年9月4日閲覧。
  21. ^ “ドメインモデル貧血症について質問したいです。|新たな発想を生み出す質問箱 Querie.me”. Querie.meで質問が回答されました. 2024年9月4日閲覧。
  22. ^ “CQRS – Simple architecture | Kariera Future Processing” (ポーランド語). kariera.future-processing.pl (2015年4月10日). 2024年9月3日閲覧。
  23. ^ “3層アーキテクチャーとは | IBM”. www.ibm.com (2023年3月21日). 2024年9月4日閲覧。
  24. ^ “Clean Coder Blog”. blog.cleancoder.com. 2024年9月7日閲覧。
  25. ^ jamesmontemagno (2023年3月29日). “インフラストラクチャの永続レイヤーの設計 - .NET”. learn.microsoft.com. 2024年9月6日閲覧。
  26. ^ “DDDを実践するための手引き（リポジトリパターン編）”. Zenn. 2024年9月6日閲覧。
  27. ^ “[ 技術講座 Domain-Driven Designのエッセンス 第2回｜オブジェクトの広場]”. www.ogis-ri.co.jp. 2024年10月16日閲覧。
  28. ^ Haywood, D., Domain-Driven Design using Naked Objects, 2009, Pragmatic Programmers
  29. ^ “Castle Project”. www.castleproject.org. 2022年8月23日閲覧。
  30. ^ “Microsoft – Cloud, Computers, Apps & Gaming” (英語). www.microsoft.com. 2022年8月23日閲覧。
  31. ^ “Domdrides - Overview”. domdrides.sourceforge.net. 2022年8月23日閲覧。
  32. ^ “CapableObjects” (英語). CapableObjects. 2022年8月23日閲覧。
  33. ^ “Home” (英語). Home. 2022年8月23日閲覧。
  34. ^ Naked Objects, Naked Objects Group Ltd, (2022-07-30), https://github.com/NakedObjectsGroup/NakedObjectsFramework 2022年8月23日閲覧。 
  35. ^ “Apache Isis”. isis.apache.org. 2022年8月23日閲覧。
  36. ^ “NReco: .NET REusable COmponents”. www.nrecosite.com. 2022年8月23日閲覧。
  37. ^ “Roma Framework: The new way to conceive Web Applications”. www.romaframework.org. 2022年8月23日閲覧。
  38. ^ “Sculptor - Generating Java code from DDD-inspired textual DSL”. sculptorgenerator.org. 2022年8月23日閲覧。
  39. ^ Dawilasoft - Sculpture - ウェイバックマシン（2012年4月22日アーカイブ分）
  40. ^ Standz - ウェイバックマシン（2016年10月28日アーカイブ分）
  41. ^ “TrueView for .NET | Agile development tools for Domain Driven Design | Home” (英語). TrueView | Agile development tools for .NET & Domain Driven Design. 2022年8月23日閲覧。
  42. ^ Technology, Volosoft Computer and. “AspNet Boilerplate - Web Application Framework” (英語). ASP.NET Boilerplate. 2022年8月23日閲覧。

外部リンク

[編集]
「https://ja-two.iwiki.icu/w/index.php?title=利用者:Br3kyokyo/sandbox/ドメイン駆動設計2&oldid=102231134」から取得