Android × DDD

はじめに 「DDD（ドメイン駆動設計）は Android には重い」 おそらく多くの Android エンジニアが、一度はそう感じたことがあるはずです。 Clean Architecture を参考に層を分け、UseCase を作り、Repository を定義し、気づけばクラスは増え続け、変更はむしろやりにくくなっている──そんな経験は珍しくありません。 一方で、Web や業務系の世界では「DDD は当たり前」のように語られています。その温度差の中で、Android エンジニアはこう悩みます。 DDD をやらないと設計力が低いと思われるのではないか でも、全部やると明らかにオーバーエンジニアリングになる 結局、どこまでやれば“正解”なのか分からない 本書は、その迷いに対する 現実的な答え を提示するために書きました。 ここで扱う DDD は、教科書的なフルセットの DDD ではありません。Aggregate Root を厳密に守る話も、巨大なエンタープライズシステムを前提とした話も、基本的にはしません。 代わりに本書が重視するのは、次の一点です。 Android アプリという制約の中で、設計が“役に立つ”状態をどう作るか。 Android アプリ開発は、UI と状態の変更が中心です。仕様変更の多くは画面に現れ、非同期処理とライフサイクルが複雑さを生みます。この文脈を無視したまま DDD の型だけを持ち込むと、設計はすぐに形骸化します。 本書では、DDD を「守るべきルール」ではなく、「判断のための視点」として扱います。 どこに境界を引くと変更が楽になるのか どの責務はドメインに置く価値があり、どれは置かなくていいのか なぜその設計を選んだのかを、言葉で説明できる状態とは何か これらを、Android の実装文脈と結びつけながら解説していきます。 想定読者は、次のような方です。 MVVM や Clean Architecture は一通り実装したことがある UseCase や Repository を作ってはみたが、しっくりきていない 「設計が大事なのは分かるが、何が大事なのか分からない」と感じている 逆に、DDD の原理や用語を網羅的に学びたい方や、厳密な理論体系を求める方には、本書は向いていないかもしれません。 この本のゴールは、あなたが次に設計をするとき、 「Android アプリという文脈で、なぜこの構造にするのか」を自分の言葉で説明できるようになること。 そして、設計がプロダクトの足かせではなく、変更に耐えるための武器 になることです。

Android アプリは「UI 駆動・状態駆動」である 変更理由の大半は「ビジネスロジック」ではない レイヤードアーキテクチャが破綻しやすい理由 MVVM + UseCase が量産されて価値を失う場合 本書が前提とする現実 Android アプリは「UI 駆動・状態駆動」である Android アプリ開発の現実を一言で表すなら、「UI と状態の変更がすべて」と言っても過言ではありません。 多くの仕様変更は、次のような形で現れます。 画面に表示する項目が増える／減る 表示条件が変わる ローディングやエラーの出し方が変わる 画面遷移の分岐が増える つまり、変更の起点はほぼ常に UI にあります。 Web や業務系システムのように「ドメインロジックが主役で、UI はその結果を表示するだけ」という構造とは、前提が大きく異なります。Android では、UI と状態管理が設計の中心に座らざるを得ません。 この事実を無視して設計を始めると、あとで必ず歪みが生まれます。 変更理由の大半は「ビジネスロジック」ではない DDD という言葉を聞くと、多くの人は「複雑なビジネスロジック」を思い浮かべます。しかし、実際の Android アプリ開発で頻発する変更理由は、それとは少し違います。 文言の変更 表示順の変更 UI の状態分岐の追加 API レスポンスの仕様変更への追従 これらは、いわゆる「ビジネスルールの変更」とは言いづらいものです。 それにもかかわらず、すべてをドメインロジックとして抽象化しようとすると、設計は一気に重くなります。結果として、「変更が楽になるはずの設計」が、逆に変更の足かせになります。 ここで重要なのは、すべての判断をドメインに集約しなくていい という認識です。 レイヤードアーキテクチャが破綻しやすい理由 多くの Android プロジェクトは、次のような構成から始まります。 UI（View / Compose） ViewModel UseCase Repository DataSource 一見すると、責務がきれいに分離されているように見えます。しかし、プロジェクトが成長するにつれて、次のような問題が表面化します。 UseCase が単なる中継層になる ViewModel が肥大化する Repository に判断ロジックが混入する これは、設計が悪いから起きる問題ではありません。Android の変更特性と、この構造が噛み合っていない ことが原因です。 UI 起点の変更が増えるほど、「どこにロジックを置くべきか」の判断が曖昧になり、結果としてレイヤー間の責務が崩れていきます。 MVVM + UseCase が量産されて価値を失う場合 MVVM + UseCase という構成は、多くの Android チームで採用されています。しかし、一定規模を超えたあたりから、次のような兆候が見え始めます。 ...

DDD のフルセットは Android には過剰になりやすい Android に必要なのは、この 3 つだけ 境界は「層」ではなく「理由」で引く ユビキタス言語はクラス名よりも会話に現れる 変更に耐える構造とは「壊しやすい」こと 捨てていい DDD の要素、慎重に使う要素 この章のまとめ DDD のフルセットは Android には過剰になりやすい DDD には多くの構成要素があります。Aggregate、Repository、Factory、Domain Service、Specification など…。これらは、複雑で長寿命なドメインを扱うシステムでは強力に機能します。 しかし、Android アプリの多くは、 画面と状態の変更が中心 要件の変化が早い チーム規模が小さい という前提のもとで開発されます。この文脈に DDD のフルセットをそのまま持ち込むと、構造はすぐに過剰になります。 ここで大事なのは、「DDD をどこまで削っても本質は残るのか」を見極めることです。 Android に必要なのは、この 3 つだけ 本書では、Android において最低限持ち込むべき DDD の要点を、次の 3 つに絞ります。 境界（責務の分離） 言葉（ユビキタス言語） 変更に耐える構造 この 3 つが守られていれば、DDD の「考え方」は十分に機能します。逆に言えば、これ以外は文脈次第で捨てて構いません。 境界は「層」ではなく「理由」で引く 多くの設計議論では、「どの層に置くか」が主語になりがちです。しかし DDD の本質は、層ではなく変更理由にあります。 なぜ、このロジックはここにあるのか どんな変更が入ったら、このコードを触ることになるのか この問いに答えられる場所に、コードを置くべきです。 Android では、UI 変更とドメイン（意味やルール）の変更の頻度が極端に違うことが多く、層だけで境界を引くと責務が混ざります。本書では、「変更理由が違うものは分ける」という単純なルールを、設計判断の軸にします。 ユビキタス言語はクラス名よりも会話に現れる ユビキタス言語というと、難しいドメイン用語を正確にクラス名に落とすことだと思われがちです。しかし、本当に重要なのは、チーム内の会話で言葉が揃っていることです。 その「状態」は何を指しているのか 「有効」とは、どの条件を満たした状態なのか 「未設定」と「空」は同じ意味なのか これらが曖昧なまま実装が進むと、設計はすぐに崩れます。 本書では、ユビキタス言語を「コードを書く前に合意しておく言葉」として扱い、クラス設計よりも前段の思考として重視します。 変更に耐える構造とは「壊しやすい」こと DDD の文脈では、「変更に強い設計」という言い方がよくされます。しかし Android 開発では、これは少し誤解を生みやすい表現です。 ...

「ドメイン = ビジネスロジック」は半分間違い Android のドメインは「判断」と「ルール」 UI ロジックとの境界線 Data 層にドメインを置いてはいけない理由 ドメインは薄くていい、でも曖昧にしてはいけない この章のまとめ 「ドメイン = ビジネスロジック」は半分間違い 「ドメインとはビジネスロジックである」 この説明は、間違いではありません。しかし、Android アプリ開発の文脈ではそれだけでは足りない、というのが本書の立場です。 Android アプリで頻繁に書かれているのは、次のようなコードです。 どの状態のときに、どの UI を出すか どの条件を満たしたら操作を許可するか どの値を正とみなし、どの値を無効とみなすか これらは純粋なビジネスロジックとは言いづらい一方で、アプリとしての振る舞いを決定する重要な判断です。Android におけるドメインは、この「判断」を含んだ領域だと捉える方が、実態に近いと言えます。 Android のドメインは「判断」と「ルール」 本書では、Android におけるドメインを、次のように定義します。 アプリがどう振る舞うかを決める、判断とルールの集合 それは必ずしも、サーバー側のビジネスルールと一致する必要はありません。 表示対象をどう選ぶか ユーザー操作をいつ無効にするか 状態遷移をどの順序で許可するか これらは UI ロジックとも密接に関わりますが、UI そのものではありません。View や Compose の中に散らばると、変更時に全体像が見えなくなります。 UI ロジックとの境界線 「これは UI ロジックか、ドメインロジックか」という問いは、しばしば議論になります。しかし、白黒をはっきり分けようとすると、設計は硬直します。 本書では、次の問いを境界判断の基準にします。 この判断は、画面が変わっても同じか このルールは、UI を捨てても意味が残るか どちらか一方でも「Yes」なら、そのロジックはドメイン側に寄せる価値があります。逆に、特定の UI 表現に強く依存しているなら、UI 側に残した方が自然です。 Data 層にドメインを置いてはいけない理由 Android プロジェクトでは、ドメインロジックが Data 層に入り込んでしまうケースが少なくありません。 Repository 内で条件分岐が増える API レスポンスをその場で解釈し始める キャッシュ有無によって振る舞いが変わる これらは一見便利ですが、結果として「なぜそうなるのか」が見えなくなります。Data 層は、あくまで データを取得・保存する責務 に集中させるべきです。 ...

なぜ UseCase が肥大化するのか UseCase は「必須レイヤー」ではない Flow を返す UseCase と suspend UseCase の境界 Command と Query を分けるという現実解 UseCase を作らないという選択肢 非同期を UseCase に閉じ込めすぎない この章のまとめ なぜ UseCase が肥大化するのか UseCase は、本来「アプリケーションとしての振る舞い」を表現するための概念です。しかし Android 開発の現場では、次のような理由で簡単に肥大化します。 画面単位で UseCase を作り始める Repository を直接触らせないための中継層になる 非同期処理（Flow / suspend）の置き場として使われる その結果、UseCase は「何をしているのか分からないが、とりあえずここを通す場所」になりがちです。これは設計ミスというより、役割が曖昧なまま使われ続けた結果 です。 UseCase は「必須レイヤー」ではない 多くのアーキテクチャ解説では、UseCase（あるいは Interactor）は必須レイヤーとして描かれます。しかし、本書の立場は明確です。 UseCase は、必要になったときにだけ導入する道具である。 UseCase が価値を持つのは、次のような場合です。 複数の UI から同じ振る舞いを呼び出す 一連の操作を「1つの意味ある処理」としてまとめたい ドメインの判断を UI から切り離したい 逆に言えば、単に Repository を呼ぶだけの処理や、画面専用の薄い処理に UseCase を挟む必然性はありません。 Flow を返す UseCase と suspend UseCase の境界 Android では、UseCase が Flow を返すのか、suspend 関数なのかで悩む場面が頻発します。この問題の本質は、非同期 API の選択ではありません。 ...

Android における Entity の寿命は短い Android で言われる Entity の多くは UI Model である data class を恐れない Immutable にこだわりすぎない sealed class / value object の使いどころ UI Model と Domain Model を分ける意味・分けない意味 Model 変換はドメインの責務ではない この章のまとめ Android における Entity の寿命は短い DDD で語られる Entity は、長い時間を生き続け、同一性を保ち続ける存在として説明されます。しかし Android アプリでは、この前提がそのまま当てはまることは多くありません。 画面仕様の変更で形がすぐに変わる API 仕様変更の影響を強く受ける UI の都合で一時的な形に変換される このような環境では、Entity を「長寿命で不変な存在」として扱おうとすると、設計が無理をし始めます。 本書では、Android における Entity を 「ID による同一性を持つが、形は変わりやすい存在」 と捉えます。寿命が短いことを前提にすることで、過剰な抽象化を避けられます。 Android で言われる Entity の多くは UI Model である Android 開発では、データベースのテーブルや API レスポンスを 「Entity」と呼ぶことがよくあります。 これらは id を持っており、一見すると DDD における Entity のように見えます。 しかし実際には、DDD が想定する Entity とは異なる役割を担っていることがほとんどです。 ...

Jetpack Compose が設計を強制するもの UI State は「ドメインの投影」である 非同期状態をドメインに持ち込まない StateHolder / Reducer パターンの現実的な使い方 ViewModel は「状態の翻訳者」 状態を持ちすぎないという選択 この章のまとめ Jetpack Compose が設計を強制するもの Jetpack Compose の登場によって、Android の設計は大きく変わりました。特に影響が大きいのが、「状態を中心に UI を組み立てる」という考え方です。 Compose では、 UI は状態の結果として描画される 状態が変われば UI が再描画される 状態を正しく持てないと UI が破綻する という前提が、半ば強制されます。 これは単なる UI フレームワークの違いではなく、設計の中心が状態管理に移った ことを意味します。 UI State は「ドメインの投影」である UI State は、しばしば「画面表示のためのデータ」として扱われます。しかし、本書では UI State を次のように捉えます。 UI State は、ドメイン上の判断結果を UI 用に投影したもの つまり、UI State 自体が判断を持つべきではありません。 表示してよいかどうか 操作を許可するかどうか 次にどの状態へ遷移するか これらはドメイン側で決まり、その結果が UI State として表現されます。この関係を意識すると、状態管理の責務が明確になります。 非同期状態をドメインに持ち込まない Loading / Error / Success といった非同期状態を、ドメインモデルに含めてしまう設計を見かけることがあります。しかし、これはドメインの関心事を曖昧にします。 ...

想定する画面要件（共通） Reducer を使わない場合 UI State ViewModel 特徴 Reducer を使う場合 UI State（同じ） Event Reducer（状態遷移の定義） ViewModel（StateHolder） 特徴 どちらを選ぶべきか Reducer を使わない方がよい場合 Reducer を使う価値が出る場合 この章のまとめ この章では、同じ要件の画面を題材に、 Reducer パターンを 使わない場合 Reducer パターンを 使う場合 の 2 つの実装を比較します。 目的は、 Reducer が「必要になる瞬間」がどこにあるのかを体感すること です。 想定する画面要件（共通） 初期表示時にデータを読み込む 読み込み中はローディング表示 成功したら一覧を表示 失敗したらエラーメッセージを表示 よくある、シンプルだが 状態は 3 種類ある画面 です。 Reducer を使わない場合 UI State data class UiState( val isLoading: Boolean = false, val items: List<Item> = emptyList(), val error: String? = null ) ViewModel class SampleViewModel( private val repository: ItemRepository ) : ViewModel() { private val _state = MutableStateFlow(UiState()) val state: StateFlow<UiState> = _state fun load() { _state.update { it.copy(isLoading = true, error = null) } viewModelScope.launch { runCatching { repository.loadItems() }.onSuccess { items -> _state.update { it.copy( isLoading = false, items = items ) } }.onFailure { e -> _state.update { it.copy( isLoading = false, error = e.message ) } } } } } 特徴 コード量が少ない 処理の流れが直線的で追いやすい 小規模な画面では十分に読みやすい 一方で、 ...

Repository は「永続化の抽象」ではない Android における Repository の最適責務 Repository にロジックが集まりやすい理由 DataSource を分けすぎる問題 キャッシュ戦略とドメイン汚染 Repository は「薄くていい」が「雑であってはいけない」 この章のまとめ Repository は「永続化の抽象」ではない DDD の文脈では、Repository はしばしば「永続化の抽象」と説明されます。しかし、この説明を Android にそのまま当てはめると、Repository の責務は一気に分かりづらくなります。 Android アプリの Repository が相手にしているのは、必ずしも「永続化」だけではありません。 API 通信 ローカル DB キャッシュ インメモリ状態 これらをすべて「永続化」と呼ぶのは、少し無理があります。 本書では、Android における Repository を次のように捉えます。 Repository は、ドメインから見た「データ取得・保存の窓口」である 重要なのは、「どこから取ってくるか」や「どう保存するか」をドメインが知らなくてよい状態を作ることです。 Android における Repository の最適責務 Android の Repository が担うべき責務は、非常にシンプルです。 必要なデータを取得する 必要なデータを保存する データ取得手段の違いを隠蔽する 逆に言えば、次のようなことは Repository の責務ではありません。 ビジネス判断 状態遷移の決定 UI 表示の都合による変換 Repository が「判断」を持ち始めた瞬間、設計は濁り始めます。 たとえば、 この場合はキャッシュを返す／返さない この条件なら空リストにする エラーを成功として扱う といった判断が Repository に入り込むと、「なぜそうなるのか」を追うのが非常に難しくなります。 Repository にロジックが集まりやすい理由 Repository は、設計が崩れ始めたときに、もっともロジックが集まりやすい場所です。その理由は単純です。 ...

Hilt は設計を良くもしないし悪くもしない DI 導入の本当の目的 モジュール分割による物理的制約 Module 地獄はなぜ起きるのか DI しなくていいものを見極める Repository と Hilt のちょうどいい距離感 BaseActivity / BaseViewModel を作らない理由 CompositionLocal を使った依存の渡し方 DI が設計を壊しているサイン この章のまとめ Hilt は設計を良くもしないし悪くもしない DI（Dependency Injection）や Hilt は、しばしば「設計を良くする魔法の道具」のように語られます。しかし、本書ではまずこの幻想をはっきり否定しておきます。 Hilt は、設計を良くもしないし、悪くもしない。 Hilt がやってくれるのは、 依存関係の生成を肩代わりすること オブジェクトのライフサイクルを管理すること だけです。 依存の向きが正しいか、責務が分離されているか、境界が妥当か──それらは Hilt では一切保証されません。むしろ、設計が曖昧なまま Hilt を使うと、その曖昧さがコード全体に固定されてしまいます。 DI 導入の本当の目的 DI を導入する目的は、テスト容易性や疎結合化だと説明されることが多いですが、Android × DDD の文脈では、もう一つ重要な目的があります。 「依存の方向」をコードとして固定すること ViewModel は Domain に依存してよい Domain は Data に依存してはいけない Data は Domain を知らなくてよい この関係を、new ではなく DI によって表現することで、「間違った依存」を作りにくくなります。Hilt は、この構造を 楽に維持するための道具 です。 モジュール分割による物理的制約 DI 導入するだけでは、間違った依存を制限することはできません。しかし、モジュール分割も合わせて導入することで、制限することができます。 ...

Clean Architecture をそのまま持ち込んだ例 何が起きたか なぜ失敗したのか 何を学ぶべきか UseCase が 100 個を超えたプロジェクト 何が起きたか なぜ失敗したのか 何を学ぶべきか ドメイン層が util 層になった話 何が起きたか なぜ失敗したのか 何を学ぶべきか テストしやすいはずが、誰もテストを書かない構造 何が起きたか なぜ失敗したのか 何を学ぶべきか この章では、Android アプリに DDD の考え方を真面目に適用しようとしたときに、構造上起こりやすい失敗例を取り上げる。 いずれも「考え方としては間違っていない」からこそ起きるものであり、設計を真剣に考えた結果として現れる。 Clean Architecture をそのまま持ち込んだ例 何が起きたか Web や書籍で学んだ Clean Architecture を、そのまま Android アプリに適用したプロジェクトでは、 presentation / domain / data が厳密に分離され すべての依存は内側に向き あらゆる処理が UseCase を経由する という構造が作られた。 構造としては美しく、レビューでも「設計は正しい」と評価されていた。しかし、実装が進むにつれて次のような問題が顕在化した。 ちょっとした画面修正でも複数レイヤーに修正が必要 UI 変更のたびに Domain 側の調整が発生 実装コストが高く、改善のスピードが落ちる なぜ失敗したのか Clean Architecture 自体が悪いのではない。問題は、Android アプリの特性を考慮せずに、そのまま当てはめたことにある。 Android アプリでは、 UI の変更頻度が高い 画面単位のロジックが多い 永続的な業務ルールが存在しないケースも多い にもかかわらず、すべてを「安定した Domain がある前提」で設計してしまったことで、構造が過剰になった。 ...

DDD は「最初から完成させるもの」ではない いきなりドメイン層を作らない 境界を 1 箇所だけ決める 言葉を揃えるところから始める リファクタリング前提の設計 小さく始めた DDD は、あとから育てられる この章のまとめ DDD は「最初から完成させるもの」ではない DDD という言葉には、どうしても「最初にきれいな構造を作らなければならない」という印象がつきまといます。 ドメイン層を用意する UseCase を定義する Repository を抽象化する Entity を厳密に設計する これらを 一気に やろうとした瞬間、設計は重くなります。 そして多くの場合、その重さに耐えきれず、DDD は「途中で放置される構造」になります。 本書が提案する DDD の始め方は、その逆です。 最初から正解を作らない。 あとで壊す前提で、小さく置く。 いきなりドメイン層を作らない DDD を始めようとすると、真っ先にやりたくなるのが「domain パッケージを作ること」です。 しかし、これはもっとも失敗しやすい第一歩でもあります。 理由は単純です。 何がドメインなのか、まだ分かっていない どこが変わりやすいか、まだ見えていない 判断とロジックがどこに集まるか、まだ確信がない この状態でドメイン層を作ると、そこはすぐに “よく分からないコード置き場” になります。 本書では、次のような始め方を推奨します。 まずは ViewModel と Repository だけで作る 判断ロジックを「ここ怪しいな」と思う場所に集める それが固まり始めたら、初めて「ここがドメインだ」と名付ける ドメインは作るものではなく、浮かび上がってくるもの です。 境界を 1 箇所だけ決める DDD を導入しようとすると、つい「すべての境界を正しく引こう」としてしまいます。 UI と Domain Domain と Data UseCase と Repository Entity と Model しかし、最初から全部やる必要はありません。 ...

要件整理と言葉の定義 境界の決定 データ → ドメイン → UI の流れ 実装スケッチ 実例から分かること この章のまとめ この章では、本書で扱ってきた考え方を、 実在する小さな Android アプリに当てはめてみます。 題材は「口座振替メモアプリ」です。 電気料金 クレジットカード サブスクリプション といった 引き落とし元 と 引き落とし先 を記録し、 「どこから、何が、どう引き落とされているのか」を把握するためのアプリです。 DDD の用語を説明する章ではありません。 どう判断し、どこに線を引いたか を追う章です。 要件整理と言葉の定義 最初にやったのは、クラス設計ではありません。 言葉を揃えること でした。 このアプリでは、次のような言葉が登場します。 口座 引き落とし 引き落とし元 引き落とし先 メモ ここで重要なのは、「それぞれが何を指すのか」を明確にすることです。 たとえば、 「口座」は銀行口座だけを指すのか クレジットカードは口座なのか 引き落とし元と引き落とし先は対等な存在か この時点で、次のように定義しました。 引き落とし元 実際にお金が減る側（銀行口座やクレジットカード） 引き落とし先 電気料金やサブスクなど、支払いの理由となるもの 口座振替 「引き落とし元」と「引き落とし先」を結びつける関係 この定義は、コードより先に決まっています。 そして、この言葉がそのままクラス名や変数名になります。 境界の決定 このアプリで最初に決めた境界は、たった一つです。 「UI は、引き落としの判断をしない」 有効かどうか 表示すべきかどうか どちらが元で、どちらが先か こういった判断は、UI に書かないと決めました。 その結果、 UI は「表示するだけ」 判断は ViewModel より下に集まる という自然な流れが生まれます。 この時点では、 ...

DDD は目的ではなく手段 Android 開発で一番大事なのは「壊しやすさ」 設計はチームとプロダクトの文脈で変わる 本書では、ドメイン駆動設計（DDD）を Android 開発の文脈で、できるだけ現実的に扱ってきました。 理論を網羅することや、正統派の実装を示すことが目的ではありません。 ここで伝えたかったのは、DDD をどう「使うか」 という視点です。 DDD は目的ではなく手段 DDD を採用すること自体に価値があるわけではありません。 価値があるのは、DDD が 判断を助けてくれること、会話を整理してくれること、そして 設計の迷いを減らしてくれること です。 もし DDD を導入した結果、 クラスが増えすぎて全体が見えなくなった 抽象が先行して実装が進まなくなった チーム内で言葉が通じなくなった のであれば、それは設計が目的化してしまっています。 設計は、プロダクトを前に進めるための道具です。 DDD もまた、そのための選択肢のひとつに過ぎません。 Android 開発で一番大事なのは「壊しやすさ」 Android アプリは、要件が変わります。 画面が増え、仕様が揺れ、API が変わり、ビジネスの都合も介入します。 その現実の中で重要なのは、 「最初から正しい設計」ではなく「あとから直せる設計」 です。 境界があるから、影響範囲が読める 言葉が揃っているから、変更点を議論できる 責務が分かれているから、壊す勇気を持てる 本書で扱ってきた DDD の要素は、すべてこの 壊しやすさ に収束します。 堅牢さのためではなく、柔らかさのための設計です。 設計はチームとプロダクトの文脈で変わる 最後に、強調しておきたいことがあります。 設計に「唯一の正解」はありません。 あなたがいるチーム、扱っているプロダクト、求められるスピードや品質によって、 最適な設計は必ず変わります。 1 人開発なら、境界は最小でいい 小さなアプリなら、ドメインは薄くていい チームが育ってきたら、言葉と責務を強く意識すればいい DDD はフルセットで導入するものではありません。 必要な部分だけを、必要なタイミングで取り入れていく。 それで十分です。 もし本書を読み終えて、 設計について少し考える余裕が生まれた 「これはドメインの話だな」と立ち止まれるようになった 設計を言葉で説明できる感覚が掴めた のであれば、この本の役割は果たせています。 DDD は、あなたの開発を縛るものではありません。 あなたの判断を、少しだけ楽にしてくれる存在であってほしい。 ...