Value Object・Entity・Aggregate - DDD のモデル構成要素

Value Object・Entity・Aggregate(集約)は、DDD(Domain-Driven Design、ドメイン駆動設計)でモデルを組み立てる時の構成要素です。Value Object は属性だけで決まる値、Entity は属性が変わっても同じ物として追跡する対象、Aggregate は不変条件を守るために、その 2 つをまとめた境界を指します。 ...

2026年8月5日 · 更新: 2026年8月18日 · 16 分 · nchika

Bounded Context - モデルが通用する範囲を区切る

Bounded Context(境界づけられたコンテキスト)とは、あるモデルが定義され、そのまま適用できる範囲を明示した境界です。Evans 氏の DDD Reference は「特定のモデルが定義され適用される境界の記述であり、多くはサブシステム、または特定のチームの担当範囲となる」と定義しています。ここでのモデルは、業務の概念を表す型と、その概念が守る規則の集まりを指します。境界の中では「注文」という語が 1 つの意味に定まり、境界の外に出た時、同じ語が同じ意味だとは仮定しません。 ...

2026年8月6日 · 更新: 2026年8月18日 · 12 分 · nchika

Repository - Aggregate の永続化を隠す境界

Repository とは、Aggregate(集約)を 1 つの単位として保存・復元する仕組みで、呼び出す側からはメモリ上のコレクションのように見えます。Eric Evans 氏の DDD Reference は、DDD(Domain-Driven Design、ドメイン駆動設計)の Repository を「ユビキタス言語で表現された、集約への問い合わせ手段」と要約しています。ユビキタス言語とは、Bounded Context の中の全員が会話・図・コードで同じ意味で使う語彙です。 ...

2026年8月6日 · 更新: 2026年8月18日 · 16 分 · nchika

Domain Event - ドメインで起きた事実を伝える

Domain Event とは、ドメインの中で既に起きた出来事を表すオブジェクトです。過去の記録なので通常は不変で、出来事が起きた時刻と、関与したエンティティの識別子を持ちます。ここでは、1 つの Bounded Context の中で Aggregate 同士を繋ぐ用途と、Bounded Context をまたいで他のシステムに伝える用途を扱います。 ...

2026年8月7日 · 更新: 2026年8月18日 · 18 分 · nchika

Sidecar - アプリケーションに機能を足す補助コンテナ

Sidecar とは、主となるアプリケーションのコンテナと同じ実行単位に一緒に配置し、そのアプリケーションに機能を足す補助コンテナです。ログの転送・設定の取得・通信の暗号化のような、業務ロジックと直交する処理を担当します。ここで言う実行単位とは、同じマシンにまとめて配置され、まとめて作られ削除されるコンテナの集まりを指します。 ...

2026年8月8日 · 更新: 2026年8月19日 · 13 分 · nchika

Ambassador - 外部との通信を仲介する補助コンテナ

Ambassador とは、アプリケーションのコンテナと同じ実行単位に配置し、外部との通信を代わりに引き受ける補助コンテナです。通信を代わりに受け取って転送する物をプロキシと呼び、Ambassador はその 1 つです。例えばアプリケーションから外に接続する構成では、アプリケーションは localhost の 1 つの宛先へ接続し、実際の接続先が何台あるのか、どれに振り分けるのかは Ambassador が判断します。 ...

2026年8月8日 · 更新: 2026年8月19日 · 11 分 · nchika

Adapter - アプリケーションの出力を外向きに揃える補助コンテナ

Adapter とは、アプリケーションと同じ実行単位に配置し、外から見える出力とインターフェースを統一する補助コンテナです。アプリケーションのコードには手を入れず、外から見た形だけを揃えます。 ...

2026年8月8日 · 更新: 2026年8月19日 · 11 分 · nchika

Anticorruption Layer - 上流のモデルを自分の語に翻訳する

Anticorruption Layer(腐敗防止層)とは、他のシステムを利用する下流が自分の責任で置く隔離層で、相手のモデルを自分のドメインモデルの語に翻訳します。Evans 氏の DDD Reference は「下流のクライアントとして、上流のシステムの機能を自分自身のドメインモデルの言葉で自分のシステムに提供する隔離層を作れ」と述べ、ACL は相手の既存のインターフェース越しに通信するため、相手のシステムへの変更をほとんど、あるいは全く必要としないとしています。 ...

2026年8月8日 · 更新: 2026年8月18日 · 20 分 · nchika

Event Sourcing - 出来事の並びを一次記録にする

Event Sourcing とは、アプリケーションの現在の状態ではなく、状態を変えた出来事の並びを永続化し、状態はその再生で復元する方式です。Martin Fowler 氏の Event Sourcing は、この方式を「アプリケーションの状態への全ての変更をイベントの列として記録する」と要約しています。 ...

2026年8月10日 · 更新: 2026年8月18日 · 12 分 · nchika

CQRS - コマンドとクエリの分離

CQRS(Command Query Responsibility Segregation、コマンドとクエリの責務分離)とは、情報の更新に使うモデルと、読み取りに使うモデルを分けられるという考え方です。Martin Fowler 氏の CQRS は、Greg Young 氏の説明で初めて知ったパターンとしてこの考え方を紹介し、中心にある発想を「情報の更新には、読み取りに使うモデルとは別のモデルを使える」と要約しています。 ...

2026年8月10日 · 更新: 2026年8月18日 · 11 分 · nchika

Feature Flag - 機能の有効・無効を切り替える設計

Feature Flag は、デプロイしたコードの振る舞いを設定や実行時の情報によって切り替える仕組みです。この実践を体系的に整理した Pete Hodgson 氏の「Feature Toggles (aka Feature Flags)」は、両者を同義として交換可能に使っています。ここでは Feature Flag で通します。 ...

2026年8月17日 · 更新: 2026年8月19日 · 10 分 · nchika

Plugin Architecture - コアを肥大化させずに機能を足す

Plugin Architecture は、コア(core、常に動く中心部分)に手を入れずに機能を追加できるようにする設計です。コアが持つのは、処理の入れ物と、拡張が満たすべき境界だけです。エディタに拡張機能を入れると、本体を差し替えずに機能が増えます。Go の database/sql がデータベースドライバを Register 関数で受け取るのも、同じ形です。 ...

2026年8月17日 · 更新: 2026年8月18日 · 11 分 · nchika

Parse, Don't Validate - 不正な状態を後段に持ち込まない

Parse, don’t validate は、「外部から来たデータを検査したら、その検査で分かった事実を型として持ち運ぶ」という設計方針です。Alexis King 氏が 2019 年に公開した「Parse, don’t validate」で示しました。 ...

2026年8月17日 · 更新: 2026年8月18日 · 10 分 · nchika