DDD - データベースのためではなく、ビジネスのためのソフトウェアを設計する (Ddd)

One domain, growing decisions

Keep one e-commerce ordering system in mind throughout this chapter. In year one, Order is a simple record carrying selected products and a total. CRUD is sufficient.

Year 1 → create, list, update orders
Year 2 → promotions and discounts
Year 3 → returns and partial payments
Year 4 → instalments, inventory reservation, shipment
Year 5 → fraud control and country-specific tax

Each need adds more than a field to Order; it adds a decision. A domain is not a software problem. It is the business problem being solved. Here it is the work of safely accepting, pricing, paying for, returning, and delivering an order.

最初の問題: コードがビジネス言語を失っているのはなぜでしょうか?

製品の初期段階では、多くの場合、テーブルを描画し、エンドポイントを記述し、レコードを追加するという単純なものです。このアプローチは間違っていません。しかし、価格設定、リターン、リスク、配送、認可ルールが急増すると、システムの価値は表に現れなくなります。それは、これらの決定が正しく実行されるかどうかにかかっています。```text Veritabanı → Table → CRUD → Service katmanı → dağınık iş kuralları

İş dünyası → Ortak dil → Domain modeli → Kod → görünür kararlar

## 最初に説明した概念```text
📦 Domain
Sistemin çözmeye çalıştığı iş alanı: örneğin sipariş, kredi veya sigorta.

📦 Domain modeli
İşin kurallarını, kavramlarını ve geçişlerini kodda temsil eden model.

📦 Ubiquitous Language / Ortak Dil
İş uzmanı, ürün ve yazılım ekibinin aynı kavram için aynı adı kullanması.

📦 Core Domain
Ürünü gerçekten farklılaştıran ve en yüksek karar karmaşıklığını taşıyan iş alanı.
````PlaceOrder` は単なる技術的な呼び出しではなく、注文の意図を伝えます。成功すると、`OrderPlaced` がビジネス上の事実になります。名前がビジネスの言語を伝えていない場合、チームは新しい機能ごとに再翻訳します。

## Why does the same order break across layers?

When product says “Preferred Customer” while engineering sees only `Status = 1`, one concept has been split into two languages. Which meaning will the next promotion rule follow? Ubiquitous language reduces that ambiguity before implementation begins.

Likewise, `order.Status = Paid` is not a safe behaviour on its own:

```text
order.Status = Paid
  ↓
Was payment actually verified?       → unknown
Was inventory reserved?              → unknown
Could the order already be cancelled?→ unknown

order.ConfirmPayment(payment)
  ↓
verifies payment evidence
applies required business rules
rejects invalid transitions

The point is not to ban setters. It is to give a business rule one owner. Team size changes the economics too: in a short-lived application built by one or two people, CRUD simplicity wins; in a product evolved for years by more than ten people, shared language and explicit ownership pay back faster.

CRUD が長期間有効に機能するのはなぜですか?

チームが小さく、製品が単一で、ルールが少ない場合、Controller → Service → Repository → Database フローは高速で簡単です。シンプルな登録画面、管理パネル、および短期間のプロトタイプの場合、このシンプルさは大きな利点となります。 DDD は CRUD に反対するイデオロギーではありません。

同じテーブルにさらにレコードが追加された場合、ブレークは発生しません。それは、同じモデルが異なるビジネス意図を表現する必要があるときに始まります。 Order は、プロモーション、税金、割引、返品、在庫予約、配送、リスク管理を一度に行うために使用されます。```text Database-first OrderRow → status = 2 → UpdateOrderStatus()

Business-first Order → ConfirmPayment() → ReserveInventory() → StartFulfilment()

## 共通言語: 翻訳税の廃止

ビジネス エキスパートが「優先顧客」と言い、コードが `UserStatus = 1` と言う場合、システムには 2 つの異なる現実があります。この違いにより、新しいチーム メンバーは誤解を引き起こし、そのルールはさまざまなサービスで繰り返され、会議は絶え間ない説明セッションになってしまいます。```text
❌ InsertNewSchoolYear()
✓ OpenNewSchoolYear()

❌ UserStatus = 1
✓ customer.MarkAsPreferred()

❌ OrderRow
✓ LoanApplication / Order / Subscription
```共通言語は、すべての技術名をビジネス用語に置き換えることではありません。モデルは、そのコンテキストでの決定を説明できるほど正確でなければなりません。地図が世界全体を示すのではなく、旅に必要な現実を示すのと同じように。ドメイン モデルは、すべてのデータではなく、関連するビジネス上の意思決定を表します。

## 貧血モデル: データをオブジェクトにし、動作を手順にする

Bloodless Domain モデルは、サービス クラスがパブリック セッターで満たされたエンティティを管理する構造です。 `OrderService`、`PricingService`、`DiscountService`、および `ShipmentService` は、時間の経過とともに異なる場所で同じルールを保持し始めます。オブジェクトはデータのみを運びます。行動はアウトのままです。```text
❌ order.Status = Paid
❌ order.Total = -10

✓ order.ConfirmPayment(payment)
✓ order.ApplyDiscount(discount)
```リッチ モデルの目的は、すべてを 1 つのエンティティにまとめることではありません。しかし、それは、行動と並行して、決して破ってはいけないシステムのルールを守ることを意味します。たとえば、支払いが確認されるまで注文は発送できません。このルールの所有者は 1 人だけである必要があります。

## DDD のコストと正しいコンテキスト

DDD;それには、分析、共通言語セッション、より慎重な名前付け、そしてチームの規律が必要です。このコストは、単純なデータ入力では採算が取れません。この決定は技術的な興奮から下されたものではありません。ドメインの複雑さと変更率を考慮して判断する必要があります。

|信号 | CRUDがさらに便利 | DDD 投資は理にかなっています |
| --- | --- | --- |
|ビジネスルール |低くて安定 |多層的、重要、常に変化 |
|製品寿命 |短いプロトタイプ |長持ちする製品 |
|エラーコスト |低い |財務的または経営的に高い |
|チームトーク |ユニークな |同じ概念でも意味が異なります。

ルールの数が増えると、ソリューションのランニングコストが非線形になることがよくあります。ルール `k` が別のサービスで繰り返される場合、変更コストは少なくとも O(k) です。ルールが相互に影響を与えると、テスト ケースはより速く成長します。 DDD は魔法のようにこのコストをゼロにするわけではありません。所有権と境界線が可視化されます。

## 最初のステップ: コードを書き直すのではなく、言語を観察する

1. 最もコストのかかる意思決定が行われるワークフローを選択します。
2. ビジネスプロフェッショナルが使用する動詞と名詞を記録します。
3. 矛盾する用語を 1 つの文脈に明確化します。
4. データフィールドの更新ではなく、ビジネス意図として新しい動作をモデル化します。
5. この制限での無効な状態を防ぐ動作のみを含めます。

このプロセスでは、データベース、フレームワーク、および API がアダプターになります。ドメインの所有者が決定するものではありません。

## 誤った信頼を生み出す一致```text
❌ DDD = katmanlı mimari
✓ DDD = karmaşık iş alanını modelleme disiplini

❌ DDD = çok fazla interface
✓ DDD = kararların ve kuralların doğru sahibini bulmak

❌ Her projede DDD gerekir
✓ Yatırım, karmaşık ve değişen domain'de geri döner

❌ Aggregate = entity grubu
✓ Aggregate = tutarlılığın korunacağı transaction sınırı

❌ Repository = her tablo için vardır
✓ Repository, domain'de anlamlı aggregate root'lar içindir

意思決定チェックリスト

• 最も損害の大きいビジネスエラーが発生した場合、どのルールに違反しますか?
• ビジネスの専門家とコードは、同じ概念を同じ単語で参照していますか?
• status = 2 はステータスの変更ですか、それとも意味のあるビジネス動作ですか?
• ルールの所有者は 1 人ですか。それとも別のサービスでも繰り返されるのでしょうか?
• このドメインは、分析コストが長期的に見合うほど複雑ですか?

これらの質問に対する明確な答えがない場合は、最初にエンティティまたはフレームワークを選択しないでください。まず問題、言語、境界を明確にします。

What you should remember from this article

1. DDD is not against the database;これは、ビジネス ルールがデータよりも価値があることを認識する設計アプローチです。
2. Common language, not meeting notes; It is a contract of code, API and decisions.
3. 無血モデルは、動作をサービス層に分散することにより、無効な状態のリスクを増大させます。
4. DDD is not in every project;複雑さと変化によってコストが発生する場合、投資は利益をもたらします。

ソフトウェアの価値はデータの保存にあるわけではありません。仕事の正しい決定を長期間維持する能力。

次のセクションでは、この考え方をコード レベル (値オブジェクト、エンティティ、および集計境界) に落とし込んでいきます。

Before moving to tactical patterns

Where do these business decisions live in code? Tactical DDD patterns such as Value Objects, Entities, and Aggregates answer that question. They are not the starting point, however; they are tools for protecting the language, rules, and boundaries made clear here.