メモ

https://learning.oreilly.com/library/view/learning-domain-driven-design/9781098100124/

https://github.com/vladikk/learning-ddd

⭐は引用が多すぎて結局書籍の内容を書き写してしまうことへの対策。⭐が多いほど重要なのではないか、という気持ちの表れ。

Paet 1. Strategic Design

Chapter 1. Analyzing Business Domains

What Is a Business Domain?

What Is a Subdomain?

Types of Subdomains

• core
• generic
• supporting

Core subdomains

コア・サブドメインとは、企業が競合他社とは異なることをすることである。これには、新製品や新サービスの発明、あるいは既存プロセスの最適化によるコスト削減が含まれる。

Complexity

コアサブドメインは自然に複雑になる。簡単だと参入障壁が低くてすぐ競合が現れる。

Sources of competitive advantage

CORE SUBDOMAIN VERSUS CORE DOMAIN

コア・サブドメインはコア・ドメインとも呼ばれる。

Generic subdomains

共通な機能のことを指している。認証機能やオンラインショッピングを例にあげていた。

Supporting subdomains

Supporting subdomainsは競合に対するアドバンテージなものではない。
それはCRUDであると説明してた。製品があるならそれを保存する必要があるし、インデックス化、カテゴライズする必要があるとも紹介していた。

Comparing Subdomains

Competitive advantage

Supporting subdomainsはGeneric subdomainsになれる。それをChapter 11で紹介する。
Complexityであればあるほど、価値を提供できる、と読んだ。

Complexity

コアサブドメインか、ジェネリックサブとメインか、サポーティブドメインかを分けるのは重要だ。

その判断の指標にCRUDで事足りるかどうか（サポーティブ）、アルゴリズムやビジネスプロセスをオーケストラする必要があるか（コア）。

Volatility

コアサブドメインは進化させ続ける必要がある。サポーティブドメインにコアサブドメインと同じ労力を割いても得られる価値は少ない、とのこと。

Solution strategy

コアサブドメインは内製でやりなさい。サポーティブドメインはルーキーを育てる経験値とするかアウトソーシング。ジェネリックドメインは買うかOSSで。

Identifying Subdomain Boundaries

Distilling subdomains

ドメインの内部構造をより詳しく調べてみよう。
-> そしてその調べの止め時はいつか。

Subdomains as coherent use cases

より細かいサブドメインを探すのをいつやめるかの指針として、「首尾一貫したユースケースの集合としてのサブドメイン」という定義を使うことができる。これがサブドメインの最も正確な境界である。
-> ？意味が分からない。

コアドメインは深く調べなさい。ジェネリックとサポーティブは気楽にやって、これ以上やっても何も明かさないと思ったらやめなさい。

Focus on the essentials

サブドメインを探す際には、ソフトウェアとは関係のないビジネス機能を特定し、そのように認識し、取り組んでいるソフトウェア・システムに関連するビジネスの側面に焦点を当てることが重要である。

Domain Analysis Examples

架空の会社2つを例に上げてドメインを分けてみよう、という章。

1つ目で、外注の対象であるストリーミングサービスや、ソーシャル・ネットワーキングの機能がそうなのか、という感じ。

まとめ

事業活動を理解するためのDDDを取り上げて、ビジネスドメインというものを足がかりにした。

サブドメイン

• core
• generic
• supporting

事例を想像してサブドメインを上の3つのどれにあてはまるか紹介した。

ドメインエキスパートの用語を紹介した。

Chapter 2. Discovering Domain Knowledge

Business Problems

ビジネスドメイン、サブドメインがビジネスの問題を解決するためのもの、という話だと思う。

Knowledge Discovery

ドメインエキスポートとの知識の共有がビジネスドメインの理解が、そのビジネスドメインが解決する問題にとってにとても重要だよね、という話

Language of the Business

What Is a Ubiquitous Language?

Language of the Business

Consistency

Ambiguous terms

ポリシーという単語のように文脈で判断しないと分からない単語は、 regulatory rule や insurance contract のようにきっちり分けよう。

Synonymous terms

複数の意味を一つの単語して使うのはやめよう。例えばUserは、user, visitor, administrator, accountのように分けよう。

Model of the Business Domain

What Is a Model?

モデルとは、物事や現象を簡略化して表現したもので、ある側面を意図的に強調する一方、他の側面を無視したものである。特定の用途を念頭に置いた抽象化。

例えば、マップを考えてみよう。マップは現実び世界を写実したけではない。例えば、道路、タイムゾーン、航海ナビゲーション、地形、航空ナビゲーション、地下鉄ルートのようなそれぞれの用途を目的とした地図を表現している。

Effective Modeling

有用なモデルとは、現実世界のコピーではない。その代わり、モデルは問題を解決するためのものであり、その目的のために十分な情報を提供するものでなければならない

モデルの本質は抽象化である。抽象化という概念は、不必要な詳細を省き、目の前の問題を解決するために必要なものだけを残すことで、複雑さを処理することを可能にする。

Modeling the Business Domain

⭐⭐

The model is supposed to capture the domain experts’ mental models

Continuous Effort

共通な知識を広げて、育てて、ユビキタス言語を継続して進化していこうという話

Tools

用語集は静的（名詞、エンティティ、processes、ロール）なものを表現するには適している。けど振る舞いに関してはそこまで適していない。振る舞いはGherkin languageというものを使ったらいい。つまりは用語集とGherkinの２つを使うといいのでは、とのこと。

Gherkin language

Scenario: Notify the agent about a new support case
    Given Vincent Jules submits a new support case saying:
    """
    I need help configuring AWS Infinidash
    """
    When the ticket is assigned to Mr. Wolf
    Then the agent receives a notification about the new ticket

given - when - then

他にもNDependがある、とのこと。

Challenges

すべてのステークホルダーが相互理解できる、ビジネスドメインを表現するユビキタス言語を育てることは実際は難しい。忍耐持ってがんばって。

Conclusion

（ドメインエキスパートとの、全てのステークホルダーとの）コミュニケーション、知識の共有
ユビキタス言語の育成。あいまいさとあ暗黙の前提をの排除、意味の一貫性。その育成の継続。
用語集やGherkin testsの紹介がドキュメント化や管理の作業を和らいでくれる。
そしてユビキタス言語をずっと使い続けましょう、とのこと。

Chapter 3. Managing Domain Complexity

組織のスケールによって同じビジネスドメインを異なるモデルを使用している。

Inconsistent Models

同じ言葉を部署によって違う意味で使っている場合どうだろう。この章の例ではlead。
よく見るアプローチとして、2つあり、1つ目は一つのモデルで複数のモデルを表現。“jack of all trades, master of none.”と表現してた。意味は器用貧乏。複雑さを解決できないのでおすすめしない。2つ目はprefixをつけて、モデルを表現。この章の例ではmarketing leadとsales lead。相反するモデルの実装が近ければ近いほど、間違いを犯しやすくなる、とのこと。またユビキタス言語で考えると、そのような言葉で会話しないのでよくない。

ではどうするか、bounded context patternはどうか。

What Is a Bounded Context?

ドメイン駆動設計における解決策は簡単で、ユビキタス言語を複数の小さな言語に分割し、それぞれを適用可能な明示的なコンテキスト、つまり境界コンテキストに割り当てることである。

境界コンテキスト = bounded context

さきの例でいうと、marketing contextのleadとsales contextのleadに分けられる。

ある意味で、用語の衝突や暗黙のコンテキストは、それなりの規模のビジネスにはつきものである。bounded contextパターンでは、コンテキストはビジネス・ドメインの明示的かつ不可欠な部分としてモデル化される。

Model Boundaries

⭐

地下鉄の地図が航海のナビゲーションには役に立たないように、ある境界のあるコンテクストではどこにでもある言語でも、別の境界のあるコンテクストの範囲ではまったく無関係であることがある。

境界コンテキストは、ユビキタス言語の一貫性の境界である。ある言語の用語、原則、ビジネス・ルールは、その境界コンテキストの内部でのみ一貫している。

Ubiquitous Language Refined

⭐

ユビキタス言語は、組織全体で「ユビキタス」に使われ、適用されるべきだという意味での「ユビキタス」ではない。

ユビキタス言語がユビキタスであるのは、その境界のあるコンテキストの中だけである。

Scope of a Bounded Context

境界コンテキストはどう区切るか。
あんまりいいヒントが得られなかった。

クリーンアーキテクチャの本には同じ理由で同じタイミングで変更するものは同じコンポーネント群（=境界コンテキスト）に纏められるべきと紹介していた。逆に別な理由で違うタイミングで変更が入るならそれは同じコンポーネント群ではない。

Bounded Contexts Versus Subdomains

Subdomains

ビジネスドメインを分析して、サブドメインを特定する（そしてコア、サポート、ジェネリックのように分類する）。

Bounded Contexts

設計上の決定

The Interplay Between Subdomains and Bounded Contexts

サブドメインはビジネス戦略によって定義される。しかし、特定のプロジェクトのコンテキストと制約に対処するために、ソフトウェア・ソリューションとその境界コンテキストを設計することができます。

Boundaries

Physical Boundaries

バウンデッド・コンテキストは複数のサブドメインを含むことができる。その場合、バウンデッドコンテキストは物理的な境界であり、各サブドメインは論理的な境界となる。論理的な境界は、名前空間、モジュール、パッケージなど、プログラミング言語によって異なる名前を持つ。

Ownership Boundaries

Bounded Contexts in Real Life

コンテキストによって意味が異なる例を紹介

Semantic Domains

Science

Buying a Refrigerator

モデルは現実世界の実体をコピーするものではない。その代わり、モデルには目的、つまり解決すべき問題があるはずだ。

モデルは、目の前のタスクに無関係な余計な情報を省くべきである。また、複数のもっと単純なモデルでそれぞれの問題を効果的に解決できるのであれば、複雑な万能モデルを設計する必要はない。

Chapter 4. Integrating Bounded Contexts

a type of team collaboration:
cooperation
customer–supplier
separate ways.

Cooperation

Partnership

Shared Kernel

Customer–Supplier

提供する、消費する関係があり、境界コンテキストで区切られている時のパターンを紹介

Conformist

Anticorruption Layer

Open-Host Service

サプライヤー側（上流側）にパブリックなインタフェースを持つ。それに下流は依存する。依存逆転の原則の話だと思う。

Separate Ways

協力しない方針の紹介

Communication Issues

チームが協力し、合意することが難しい場合、別々の道を歩み、複数の境界のあるコンテキストで機能を重複させる方が費用対効果が高い場合がある。

いいの？この選択肢とって。開発組織が大きいとこのようなケースも全然ありえるのかな。

Generic Subdomains

ロギングの例を紹介していた。

Model Differences

あまりに異なりすぎて、協力するほうがコストというようなことが紹介されていた。

Context Map

引用: https://alok-mishra.com/2021/06/29/ddd-context-mapping-by-example-policy-management/

他リソース: https://www.infoq.com/articles/ddd-contextmapping/

Maintenance

https://contextmapper.org/

Limitations

Conclusion

⭐

Partnership
Conformist
Anticorruption layer
Open-host service
Separate ways

参考

https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap3.html

Chapter 5. Implementing Simple Business Logic

Transaction Script

Implementation

トランザクション的な振る舞いは、パターンの名前である「トランザクション・スクリプト」に反映されている。

It’s Not That Easy!

分散システムになるとその実現は難しくなる。

optimistic concurrency control: 楽観的並行性制御

以下のような形で実現したらどう、と紹介していた

_db.Execute(@"UPDATE Users SET visits=visits+1
                      WHERE user_id=@p1 and visits = @p2",
                      userId, visits);

When to Use Transaction Script

しかし、この単純さがこのパターンの欠点でもあります。ビジネスロジックが複雑になればなるほど、トランザクション間でビジネスロジックが重複しやすくなり、その結果、重複したコードが同期されなくなり、動作に一貫性がなくなる。その結果、トランザクションスクリプトをコアサブドメインに使うべきではありません。このパターンではコアサブドメインのビジネスロジックの複雑さに対応できないからです。

Active Record

Implementation

When to Use Active Record

⭐

トランザクションスクリプトパターンの場合と同様に、アクティブレコードパターンは、サブドメインのサポート、汎用サブドメインのための外部ソリューションの統合、またはモデル変換タスクに適している。両パターンの違いは、アクティブレコードが複雑なデータ構造をデータベースのスキーマにマッピングする複雑さに対処している点である。

Be Pragmatic

Conclusion

Transaction script
Active record

⭐

Chapter 6. Tackling Complex Business Logic

History

Domain Model

Implementation

Complexity

ドメインビジネスロジック自体が複雑なものなので、それをモデリングするオブジェクトは他の複雑なものを追加してはならない。インフラストラクチャルなものやフレームワーク的なものはくっつけず、プレインなオブジェクトでいることを求められる

Ubiquitous language

技術的関心を脇に置き、ビジネスロジックを中心に考えることで、ドメインオブジェクトは境界コンテキストにおけるユビキタス言語に従うことになる。

Building Blocks

Value object

⭐

immutable object

Entities

エンティティは値オブジェクトの対極にある。エンティティの異なるインスタンスを区別するために、明示的な識別フィールドが必要です。

Aggregateのコンテキストでentityは使用するとのこと。Aggregateを使用しない場合はentityを使用しない、のだと言っていると思う。

Aggregates

⭐

アグリゲートはエンティティです。明示的な識別フィールドを必要とし、その状態はインスタンスのライフサイクル中に変化することが期待されます。しかし、単なるエンティティ以上のものです。このパターンの目的は、データの一貫性を保護することです。集約のデータは変更可能であるため、その状態を常に一貫性を保つためにパターンが対処しなければならない意味と課題があります。

Consistency enforcement

stateを変更する方法は2つあると紹介。

一つはパプリックインタフェースなメソッド

public class Ticket
{
    ...

    public void AddMessage(UserId from, string body)
    {
        var message = new Message(from, body);
        _messages.Append(message);
    }

    ...
}

もう一つはコマンドをパラメータにわたす方法、とのこと

public class Ticket
{
    ...

    public void AddMessage(UserId from, string body)
    {
        var message = new Message(from, body);
        _messages.Append(message);
    }

    ...
}

集約のパブリックインターフェースは、入力を検証し、関連するすべてのビジネスルールと不変量を実施する責任を負います。この厳密な境界はまた、集約に関連するすべてのビジネスロジックが、集約自体という一箇所で実装されることを保証します。

Transaction boundary

Hierarchy of entities

Referencing other aggregates

⭐

経験則では、集約はできるだけ小さく保ち、集約のビジネスロジックによって強く一貫した状態であることが要求されるオブジェクトのみを含める

The aggregate root

Domain events

ドメインイベントは、ビジネスドメインで発生した重要なイベントを記述するメッセー ジである。

ex.
Ticket assigned
Ticket escalated
Message received

ドメインイベントは、アグリゲートのパブリックインターフェイスの一部です。アグリゲートはドメインイベントをパブリッシュします。

Ubiquitous language

aggregatesでもきちんとユビキタス言語使おうね

Domain services

どの集約や値オブジェクトにも属さない、あるいは複数の集約に関連すると思われるビジネスロジックに遭遇することがあります。このような場合、ドメイン駆動設計では、ロジックをドメインサービスとして実装することを提案します。

1つのデータベーストランザクションで1つの集約のインスタンスのみを変更するという集約パターンの制限を常に念頭に置くことが重要です。ドメインサービスは、この制限を回避する抜け道ではありません。

ドメインサービスは

ビジネス・ロジックをホストするためのステートレス・オブジェクトに過ぎない。

Managing Complexity

Conclusion

⭐⭐

ドメインモデルパターンは、複雑なビジネスロジックのケースを対象としている。3つの主要な構成要素からなる：

Value objects
Aggregates
Domain services

Chapter 7. Modeling the Dimension of Time

Event Sourcing

Search

変更の履歴を含む連絡先情報を使ってリードを見つけたい、の要望を表現したモデルの紹介

（ta.toshioの感想: 最新の状態がデータベースに永続化されないのだから最新の状態の検索性は困難になるのでは？ -> スナップショットをとればいいのか？）

Analysis

さまざまなリードに対して、フォローアップコールの予定数を取得したい、モデルの紹介

Source of Truth

イベント・ソーシング・パターンが機能するためには、オブジェクトの状態に対するすべての変更をイベントとして表現し、永続化する必要がある。これらのイベントはシステムの真実のソースとなる（これがパターン名の由来である）。

Event Store

イベントストアは、追記のみのストレージであるため、イベントの変更や削除を許可してはならない。イベント・ソーシング・パターンの実装をサポートするために、イベント・ストアは最低限以下の機能をサポートする必要がある：特定のビジネス・エンティティに属するすべてのイベントをフェッチし、イベントを追加する。

Event-Sourced Domain Model

⭐

aggregate’s rehydration logic の例

18  public class Ticket
19  {
20      ...
21      private List<DomainEvent> _domainEvents = new List<DomainEvent>();
22      private TicketState _state;
23      ...
24 
25      public Ticket(IEnumerable<IDomainEvents> events)
26      {
27          _state = new TicketState();
28          foreach (var e in events)
29          {
30              AppendEvent(e);
31          }
32      }

Advantages

• Time traveling
• Deep insight
• Audit log
• Advanced optimistic concurrency management

Disadvantages

• Learning curve
• Evolving the model
• Architectural complexity

Frequently Asked Questions

Performance

Deleting Data

Why Can’t I Just…?

⭐

ステート・ベースのモデルで作業を続けながら、同じデータベース・トランザクションで、ログをログ・テーブルに追加できないのはなぜですか？
状態ベースの表現が真実のソースとして使用される場合、追加ログテーブルのスキーマは通常、すぐにカオスに劣化する。必要な情報がすべて書かれ、それが正しいフォーマットで書かれていることを強制する方法はない。

Conclusion

⭐

Chapter 8. Architectural Patterns

Business Logic Versus Architectural Patterns

Layered Architecture

書籍引用

Presentation Layer

GUI
CLI
REAT API
Subscription to events in a message broker
Message topics for publishing outgoing events

Business Logic Layer

Entities
Rules
Processes

Data Access Layer

Database
Message bus
Object storage

Communication Between Layers

Variation

⭐

レイヤード・アーキテクチャ・パターンが、サービス・レイヤという追加レイヤで拡張されるのはよくあることだ。

サービス・レイヤーは、プログラムのプレゼンテーション・レイヤーとビジネス・ロジック・レイヤーの中間的な役割を果たす。
サービス・レイヤーは、ビジネス・ロジック・レイヤーのファサードとして機能する。

Terminology

When to Use Layered Architecture

⭐

ビジネスロジックとデータアクセスレイヤー間の依存関係により、このアーキテクチャパターンは、トランザクションスクリプトまたはアクティブレコードパターンを使用して実装されたビジネスロジックを持つシステムに適している。

Ports & Adapters

Terminology

Dependency Inversion Principle

⭐

書籍引用

Integration of Infrastructural Components

⭐

ビジネスロジック層は、インフラストラクチャーコンポーネントを直接参照したり呼び出したりする代わりに、インフラストラクチャー層が実装しなければならない「ポート」を定義する。インフラストラクチャー層は「アダプター」を実装する。これは、異なるテクノロジーと連携するためのポート・インターフェースの具体的な実装である。

Variants

When to Use Ports & Adapters

Command-Query Responsibility Segregation

Polyglot Modeling

Implementation

Command execution model

Read models (projections)

Projecting Read Models

Synchronous projections

Asynchronous projections

Model Segregation

CQRSベースのシステムに関してよくある誤解は、コマンドはデータを変更することしかできず、データはリードモデルを通してのみ表示のためにフェッチすることができるというものです。言い換えれば、メソッドを実行するコマンドは決してデータを返してはならない。これは間違っている。このアプローチは偶発的な複雑さを生み出し、悪いユーザーエクスペリエンスにつながる。

When to Use CQRS

CQRSはイベント・ソーシング・ドメイン・モデルに適している。イベント・ソーシング・モデルでは、集合体の状態に基づいてレコードをクエリすることは不可能だが、CQRSは状態をクエリ可能なデータベースに投影することで、これを可能にする。

Scope

⭐⭐

書籍引用

Chapter 9. Communication Patterns

Model Translation

Stateless Model Translation

ステートレスモデル変換の場合、変換を所有するバウンデッドコンテキスト（アップストリームはOpen=host service、ダウンストリームはAnti corruption layer）はプロキシ設計パターンを実装し、入出力のリクエストに介入し、ソースモデルをバウンデッドコンテキストのターゲットモデルにマッピングする。

Stateful Model Translation

より重要なモデル変換の場合、例えば、変換メカニズムがソース・データを集約する必要がある場合や、複数のソースからのデータを単一のモデルに統合する必要がある場合などには、ステートフルな変換が必要になることがあります。

Aggregating incoming data

Unifying multiple sources

例としてBFF

Integrating Aggregates

だめな例を2つ紹介

Outbox

⭐

書籍引用

Saga

⭐

集計の境界内のデータだけが、強く一貫していると考えることができる。外側のすべては最終的に一貫している。

Process Manager

sagaパターンは、単純なクロスコンポーネント・ビジネス・プロセスを実装するために使うことができる。より複雑なビジネス・プロセスは、プロセス・マネージャー・パターンを使って実装することができる。どちらのパターンも、ドメイン・イベントへの非同期反応とコマンドの発行に依存している。

Chapter 10. Design Heuristics

Bounded Contexts

最初は広くコンテキストをとって、必要ならドメイン知識がついたタイミングで小さく分解してもいい。

Business Logic Implementation Patterns

⭐⭐

Architectural Patterns

⭐⭐

Testing Strategy

Testing Pyramid

ドメインモデルパターンの時フィット。

Testing Diamond

テストダイヤモンドは、統合テストに最も重点を置いている。アクティブレコードパターンを使用する場合、システムのビジネスロジックは、定義上、サービスレイヤーとビジネスロジックレイヤーの両方にまたがる。したがって、2 つのレイヤーの統合に焦点を当てるには、テストピラミッドがより効果的な選択となります。

Reversed Testing Pyramid

トランザクションスクリプトの時フィット。

Tactical Design Decision Tree

⭐⭐

Chapter 11. Evolving Design Decisions

Changes in Domains

• Core to Generic

他社に革新的なプロダクトが出てきたら、いままでコアサブドメインだったものが、ジェネリックに変わるという話

• Generic to Core
• Supporting to Generic
• Supporting to Core
• Core to Supporting
• Generic to Supporting

Strategic Design Concerns

Tactical Design Concerns

• Transaction Script to Active Record
• Active Record to Domain Model
• Domain Model to Event-Sourced Domain Model

Modeling Migration Events

Organizational Changes

• Partnership to Customer–Supplier
• Customer–Supplier to Separate Ways

Domain Knowledge

戦略的設計の観点からは、ドメイン知識のレベルに応じて境界付きコンテキストの境界を設計することは有用なヒューリスティックである。システムを境界付きコンテキストに分解するコストは、時間の経過とともに不正確であることが判明する可能性がある。したがって、ドメインロジックが不明確で頻繁に変更される場合、境界を広くして境界付きコンテキストを設計することは理にかなっている。その後、ドメイン知識が時間の経過とともに発見され、ビジネスロジックの変更が安定するにつれて、これらの広い境界を持つコンテキストは、より狭い境界を持つコンテキスト、つまりマイクロサービスに分解することができる。

Growth

Subdomains

Bounded Contexts

Aggregates

システムのビジネス要件が大きくなるにつれて、集約を小さく保つという原則を再検討することなく、新しい機能を既存の集約に分散させることが「便利」になることがあります。もし集約が大きくなって、すべてのビジネスロジックで強く一貫する必要のないデータを含むようになった場合、やはりそれは排除しなければならない偶発的な複雑さである。

⭐

Conclusion

⭐

Chapter 12. EventStorming

What Is EventStorming?

Who Should Participate in EventStorming?

What Do You Need for EventStorming?

The EventStorming Process

⭐

Step 1: Unstructured Exploration

ドメインの出来事を過去形で表現することが重要だ

このステップでは、ビジネス領域で起こりうることをブレインストーミングする。

Step 2: Timelines

次に、参加者は生成されたドメインイベントを確認し、ビジネスドメインで発生する順番に整理する。

Step 3: Pain Points

ボトルネックや、自動化が必要なとこや、文書化が必要なとこ、理解が深まっていないとことをあとで振り替えれるようにマークしておこう。

Step 4: Pivotal Events

Pivotal events are an indicator of potential bounded context boundaries.

Step 5: Commands

ドメインイベントがすでに起こったことを記述するのに対して、コマンドはイベントやイベントの流れの引き金となったものを記述する。コマンドはシステムのオペレーションを記述し、ドメイン・イベントとは逆に、命令形で記述される。

Step 6: Policies

Step 7: Read Models

Step 8: External Systems

Step 9: Aggregates

Step 10: Bounded Contexts

Variants

When to Use EventStorming

Facilitation Tips

Watch the Dynamics

Remote EventStorming

Chapter 13. Domain-Driven Design in the Real World

Strategic Analysis

Understand the Business Domain

Core subdomains

Generic subdomains

Supporting subdomains

Explore the Current Design

問題領域に慣れたら、ソリューションとその設計決定について調査を続けることができる。まず、高レベルのコンポーネントから始めます。これらは必ずしもDDDの意味での境界コンテキストではなく、ビジネスドメインをサブシステムに分解するために使用される境界です。

探すべき特徴的な特性は、コンポーネントの分離されたライフサイクルです。

他から独立して進化、テスト、デプロイできるものをチェックする。

Evaluate the tactical design

Evaluate the strategic design

Modernization Strategy

Strategic Modernization

Tactical Modernization

Cultivate a Ubiquitous Language

Strangler pattern

Refactoring tactical design decisions

Pragmatic Domain-Driven Design

⭐

DDDが提供するすべてのツールを適用する必要はない。たとえば、何らかの理由で戦術的なパターンがあなたには使えないかもしれない。もしかしたら、他のデザイン・パターンの方があなたの特定の領域でよりうまく機能するから、あるいは他のパターンの方がより効果的だと思うから、他のデザイン・パターンを使うことを好むかもしれません。それはそれで構わない！

ドメイン駆動設計とは、集約やバリュー・オブジェクトのことではないことを、もう一度言っておく価値がある。ドメイン駆動設計とは、ビジネス・ドメインにソフトウェア設計の決定を委ねることだ。

Selling Domain-Driven Design

Undercover Domain-Driven Design

Ubiquitous language

Bounded contexts

なぜ、すべてのユースケースに対して単一のモデルを設計するのではなく、問題志向のモデルを設計する方が良いのでしょうか？オールインワン」のソリューションが有効なことはほとんどないからだ。

Tactical design decisions

Event-sourced domain model

Chapter 14. Microservices

What Is a Service?

What Is a Microservice?

Method as a Service: Perfect Microservices?

Design Goal

System Complexity

書籍引用

Microservices as Deep Services

効果的なモジュールは深い：シンプルなパブリック・インターフェースが複雑なロジックをカプセル化する。効果的でないモジュールは浅い：浅いモジュールのパブリック・インターフェースは、深いモジュールよりもはるかに少ない複雑さをカプセル化する。

Microservices as Deep Modules

⭐

システムの複雑性の観点から見ると、ディープモジュールはシステムの大域的な複雑性を減らし、シャローモジュールは局所的な複雑性をカプセル化しないコンポーネントを導入することで複雑性を増やす。

システムをマイクロサービスに分解できる閾値は、マイクロサービスが属するシステムのユースケースによって定義される。モノリスをサービスに分解すると、変更を導入するコストが下がる。システムをマイクロサービスに分解すれば、変更にかかるコストは最小限に抑えられる。しかし、マイクロサービスの閾値を超えて分解を続けると、深いサービスはどんどん浅くなっていく。インターフェイスはまた増えていく。今度は統合の必要性から変更の導入コストも上がり、システム全体のアーキテクチャは恐ろしい分散した大きな泥の玉になってしまう。

Domain-Driven Design and Microservices’ Boundaries

Bounded Contexts

マイクロサービスとバウンデッドコンテキストの関係は対称的ではない。マイクロサービスはバウンデッドコンテキストであるが、すべてのバウンデッドコンテキストがマイクロサービスであるわけではない。一方、バウンデッドコンテキストは、有効な最大のモノリスの境界を示す。

Aggregates

Subdomains

⭐

マイクロサービスを設計するための、よりバランスの取れたヒューリスティックな方法は、サービスをビジネス・サブドメインの境界に合わせることである。

サブドメインの粒度と、"どのように "ではなく "何を "という機能に焦点を当てることで、サブドメインは自然に深いモジュールになる。サブドメインの記述（機能）は、より複雑な実装の詳細（ロジック）をカプセル化する。サブドメインに含まれるユースケースの首尾一貫した性質も、結果としてモジュールの深さを保証します。多くの場合、これらを分割すると、より複雑なパブリック・インターフェイスになり、その結果、モジュールの深さも浅くなります。これらのことから、サブドメインはマイクロサービスを設計する際の安全な境界となります。

Compressing Microservices’ Public Interfaces

Open-Host Service

Anticorruption Layer

Conclusion

⭐

Chapter 15. Event-Driven Architecture

Event-Driven Architecture

Events

Events, Commands, and Messages

イベント
すでに起こった変更を説明するメッセージ

コマンド
実行しなければならない操作についてのメッセージ。

Structure

Types of Events

Event notification

イベント通知は、他のコンポーネントが反応する、ビジネスドメインの変更に関するメッセージである。

イベント通知は冗長であってはならない。ゴールはイベントに関して関係者に通知することであるが、通知はサブスクライバーがイベントに反応するために必要なすべての情報を運ぶべきでない。

Event-carried state transfer

Event-carried state transfer (ECST)メッセージは、プロデューサの内部ステートの変 更をサブスクライバに通知する。イベント通知メッセージとは逆に、ECSTメッセージは、状態の変化を反映するすべてのデータを含む。

Domain event

Domain events versus event notification

Event notificationは、他のコンポーネントとの統合を緩和することを意図して設計されている。一方、Domain eventは、ビジネス・ドメインをモデリングし、記述することを意図している。ドメイン・イベントは、外部のコンシューマがそれらに興味がなくても、有用である。これは、ドメインイベントがすべての可能な状態遷移をモデル化するために使用される、イベントソースシステムで特に当てはまります。利用可能なすべてのドメイン・イベントに興味を持つ外部コンシューマがいると、最適な設計ができなくなります。

Domain events versus event-carried state transfer

ECSTメッセージは、プロデューサーのデータのローカルキャッシュを保持するのに十分な情報を提供する。単一のドメインイベントがそのようなリッチなモデルを公開することは想定されていない。

ドメインイベントに含まれるデータは、集約の状態を記述することを意図していない。その代わりに、ライフサイクル中に発生したビジネスイベントを記述します。

Event types: Example

⭐

Designing Event-Driven Integration

第3章で説明したように、ソフトウェア設計は主に境界に関するものである。境界は、何が内部に属し、何が外部に残り、そして最も重要なことは、何が境界を越えるのか、つまり基本的にコンポーネントが互いにどのように統合されるのかを定義します。EDAベースのシステムにおけるイベントは第一級の設計要素であり、コンポーネントの統合方法とコンポーネントの境界そのものに影響を与えます。イベント・メッセージの正しいタイプを選択することが、分散システムを作る（デカップリング）か壊す（カップリング）かを決定します。

Distributed Big Ball of Mud

Temporal Coupling

Functional Coupling

Implementation Coupling

Refactoring the Event-Driven Integration

⭐⭐

コンシューマ主導のコントラクト・パターンに従うことができます。コンシューマが必要とするモデルをプロジェクションし、それをバウンデッド・コンテキストの公開言語の一部にします。その結果、コンシューマはCRMの実装モデルを意識することなく、必要なデータをすべて得ることができます。

Open-host serviceを使ってevent-carried state transferをメッセージのタイプとして利用する例を紹介していた

Event-Driven Design Heuristics

Assume the worst

Use public and private events

外部バウンデッドコンテキストとの通信には、ドメインイベントを控えめに使用する。専用のパブリック・ドメイン・イベントのセットを設計することを考えましょう。

Evaluate consistency requirements

16 Chapter 16. Data Mesh

Analytical Data Model Versus Transactional Data Model

Fact Table

Dimension Table

Analytical Models

Analytical Data Management Platforms

Data Warehouse

Data Lake

Challenges of Data Warehouse and Data Lake Architectures

Data Mesh

Decompose Data Around Domains

Data as a Product

Enable Autonomy

Build an Ecosystem

Combining Data Mesh and Domain-Driven Design

Appendix A. Applying DDD: A Case Study

Five Bounded Contexts

Business Domain

Bounded Context #1: Marketing

Appendix A. Applying DDD: A Case Study

Five Bounded Contexts

Business Domain

Bounded Context #1: Marketing

Bounded Context #2: CRM

Bounded Context #3: Event Crunchers

Bounded Context #4: Bonuses

Bounded Context #5: The Marketing Hub

Discussion

Ubiquitous Language

Boundaries of Bounded Contexts