記事

型で保証できるものとできないもの 普段私は Kotlin の型システムを活用して、コンパイル時に不正な状態を表現できない設計を心がけています。 例えば、 sealed class で状態を表現する value class で ID をラップする null を型で排除する といった方法です。 しかし、あるとき「存在する PaymentId しか関数に渡せないようにできないか？」と考えました。 結論から言うと、これは型だけでは保証できません。 なぜなら、 fun observePayment(id: PaymentId) という関数に渡された ID が実際にデータベースに存在するかどうかは、コンパイル時には分からないからです。 型で保証できるのは、 null ではない 状態の種類 値の構造 不変条件 など、コンパイル時に判定できる性質です。 一方で、 DB にレコードが存在する ファイルが存在する API が応答する 他ユーザーによって削除されていない といったものは実行時の状態に依存するため、型だけでは保証できません。 当たり前と言えば当たり前なのですが、今回再確認したことは 型で保証できるのは「コンパイル時に確定できること」 実行時の状態に依存することは、実行時チェックで保証する ということでした。 例えば「一覧画面から選択された ID なので存在するはず」という前提がある場合でも、その後、別の画面からそのデータが削除されている可能性もあるため、 ID が存在していない可能性もあります。 その場合は、 Repository や UseCase で requireNotNull() を使ったり、独自例外を投げたりして不整合を検知することになります。 型安全な設計を考える際は、「これはコンパイル時に分かる情報か？それとも実行時にしか分からない情報か？」を意識すると、どこまでを型で表現すべきか判断しやすくなります。

「起きたこと」で名前を付けるか、「意図」で名前を付けるか アプリ開発をしていると、 OnClickPayment OnClickDelete OpenPaymentEdit ShowDeleteDialog のように、イベントや関数の名前をどう付けるべきか迷うことがあります。 特に ViewModel を使った設計では、 「起きたこと」を名前にするべきか 「やりたいこと（意図）」を名前にするべきか で悩むことがよくあります。 結論 私は次のように考えています。 UI → ViewModel は「起きたこと」 ViewModel → UI は「意図」 で名前を付けると整理しやすくなります。 ただし、この方針は絶対ではありません。 この方針を破ったほうが自然な名前になる場合も多々あることに注意してください。 UI → ViewModel は「起きたこと」 例えば Compose の画面から ViewModel にイベントを伝える場合です。 viewModel.onClickPayment() viewModel.onClickDelete() viewModel.onTextChanged(text) ここで ViewModel に伝えたいのは、 「ユーザーが何をしたか」 です。 まだ ViewModel は、その結果として何を行うかを決めていません。 そのため、 fun onClickPayment() fun onClickDelete() fun onTextChanged(text: String) のような名前が自然です。 ViewModel → UI は「意図」 一方で、ViewModel から UI に送るイベントは少し性質が異なります。 例えば、 sealed class UiEvent { data class OpenPaymentEdit( val paymentId: Int ) : UiEvent() data object ShowDeleteDialog : UiEvent() data class ShowSnackbar( val messageRes: Int ) : UiEvent() } ここで ViewModel が伝えたいのは、 ...

UiState にドメインモデルをどこまで持たせるべきか考えた Jetpack Compose で画面実装をしていると、よく悩むのが、 UiState にどこまでドメインモデルを持たせるべきか UI専用モデルをどこまで作るべきか という問題です。 最近、自分は Id の扱いについて考える機会がありました。 きっかけ たとえば、以下のような UiState があるとします。 data class UiState( val id: Id = Id.Unassigned, val name: String = "", ) { sealed interface Id { data object Unassigned : Id data class Assigned(val value: Int) : Id } } 一方で、ドメインモデル側にも、ほぼ同じ定義があります。 sealed interface PaymentId { data object Unassigned : PaymentId data class Assigned(val value: Int) : PaymentId } さらに、今後ほかの画面でも、 PaymentEditUiState.Id PaymentDetailUiState.Id PaymentListItemUiState.Id のような、似た ID 型が増えていく可能性がありました。 そこで、 「これ、UiState ごとに定義する必要ある？」 という疑問が出てきました。 結論 今回のケースでは、 ドメイン側の ID 型をそのまま UiState で使う ...

AI 時代のエンジニアのキャリアについて考える（2026年4月現在） 前提 AI にできることはどんどん拡大している。 使い方次第で、様々な役割を果たすことができるようになっている。 各組織の CTO を筆頭に、 AI 利用のベストプラクティスを探る動きがあるが、いろいろなことができすぎて、最適解を定義するのは難しい。 これらを踏まえて、 AI 時代のエンジニアの生存戦略を考えてみる。 AI にできないこと AI の活用方法や可能性が無限大であることが、思考を整理するうえで妨げになっていると感じる。 そのため、まずは、 AI には絶対に無理なことは何かを考えてみる。 前提を把握しきれない AI に指示を出すのは人間なので、その人間がすべての前提を AI に伝えられなければ、納得できる結果が得られない。 やめる判断 AI は指示されれば、基本的にはその指示通りに動く。仮に、その指示が、やめたほうがいい設計や要件の場合でも続けてしまう。 要件や設計の矛盾を指摘する AI は矛盾点を指摘することがあまりないように感じる。 矛盾したまま進めると、後になって崩壊するリスクが存在する。 判断を下す 様々な案を提案はしてくれるけど、最終的にメリットとデメリットを比較して判断を下すのは常に人間側になる。 影響範囲を示す AI は指示したとおりに実装はしてくれるが、その実装がどこまで影響があるのかは提示してくれないように感じる。 提示してくれたとしても、コードレベルで修正内容を提示する程度ではないだろうか。 その修正をレビューし、問題がないかを判断する責任は人間側にあると思う。 人間がやったほうが早いこと 意見が対立した場合の調整 ビジネスサイド / デザイナー / エンジニア間で意見が対立した場合、それぞれの意見を聞いたうえで、最終的な判断をするのは人間しかできない。 例えば、人間同士の会話のように相手の話している最中に割り込むことがしずらいかな？ または、 AI は文脈を理解していない可能性があり、プロジェクトの詳細などを一から説明しないとスタート地点に立てないことがある。 または、人間同士なら一緒に働いていれば、相手の思考プロセスがわかるようになり、最適な対応ができる可能性があるが、 AI には難しいことがある。 AI に実装してもらった場合に困ること AI が書いたコードを読めるのか問題 私は、「わかりやすいコードは、読んだだけで仕様がわかるもの」だと考えている。 読んでいて、仕様がわからないようなコードは読むのが辛い。 そのコードがベースになっても大丈夫なのか問題 機能を追加する際に、 AI が書いたコードがベースになり、それに合わせる形で実装が追加されていく。 ベースが悪いと、追加実装時に、悪いコードに引きずられて、どんどんと悪いコードが増殖していく。 AI が得意な分野 明確な仕様がある 評価基準が決まっている パターンが存在する エンジニアが進むべき方向 「決める側」に回る回数を増やす ...

題材 リポジトリがドメインに依存するのはありか？ ドメインを知りすぎた実装 ドメインを知りすぎない実装 今回は、リポジトリがドメインに依存しすぎた話を書きたいと思います。 題材 題材は、口座振替管理アプリで、ローカルの DB にデータを保存する場合の話です。 支払情報編集画面という画面があり、この画面では、データの新規登録と既存データの更新が可能になっています。 この「新規登録」処理と「更新」処理を行う際に、リポジトリはどこまでドメインを知っていていいのか？という話になります。 リポジトリがドメインに依存するのはありか？ まず、クリーンアーキテクチャ的には、リポジトリがドメインに依存することは間違ってはいません。 ただし、どこまで知っていてよいのかは検討の余地があるというのが今回の学びです。 ドメインを知りすぎた実装 まずは、ドメインを知りすぎた良くない実装を紹介します。 以下は、支払情報を表す Payment オブジェクトです。 sealed interface Payment { val name: PaymentName val payerId: PayerId data class Persisted( val id: PaymentId, override val name: PaymentName, override val payerId: PayerId = PayerId.NONE, ) : Payment data class InMemory( override val name: PaymentName, override val payerId: PayerId = PayerId.NONE, ) : Payment } 編集の場合は、すでにデータが永続化されているため、 Persisted オブジェクトで表現します。永続化済みのデータは ID を持っています。 新規登録の場合は、 ID を持っていないため InMemory オブジェクトで表現します。 リポジトリ側には、この Payment オブジェクトが渡され、このオブジェクトの実態が Persisted なのか、 InMemory なのかによって、新規作成か、更新かを分けています。 ...

すぐに思いつく実装 「新規作成 or 編集」を型で表現する なぜエラーになるのか 正しい設計：Navigation はプリミティブ型を渡す 重要なポイント Navigationの責務 UI の責務 一覧画面から「新規作成」と「編集」の両方に遷移するケースは、アプリ開発でよくあります。 例えば以下のような仕様です： リストのアイテムをタップ → 編集画面へ 「追加」ボタンをタップ → 新規作成画面へ 画面UIは同じ（内部の動作だけ異なる） すぐに思いつく実装 すぐに思いつく実装方法は以下ではないでしょうか？ Navigation の定義は以下の通り NavHost( navController = navController, startDestination = startDestination, modifier = modifier, ) { // リスト画面 composable<ItemList> { PayeeListScreen( onClickAdd = { navController.navigate(RegisterItem(null)) }, onClickItem = { itemId -> navController.navigate(RegisterItem(itemId)) } ) } // 登録・編集画面 composable<RegisterItem> { backStackEntry -> val registerItem: RegisterItem = backStackEntry.toRoute() RegisterItemScreen( onClickNavigateUp = { navController.navigateUp() }, itemId = registerItem.id ) } Destination の定義は以下の通り ...

はじめに ドメイン設計だけでは埋まらない違和感 ワイヤーフレームを作って起きた変化 1. ユーザーの行動が具体化される 2. 必要なデータと制約が見えてくる 3. ドメイン設計の「抜け」が露出する ワイヤーフレームは見た目のためではない まとめ おわりに はじめに 最近、アプリ開発の中で「ワイヤーフレーム」を使い始めたところ、思いがけずドメイン設計が大きく前進しました。 ワイヤーフレームとは、 Figma などを使って作る UI デザインの一種です。 ただし、色やフォントサイズなどの細かい UI にはこだわりません。 ボタンや入力欄であることがわかれば良いという程度のラフな UI デザインのことを言います。 もともとドメイン駆動で設計を進めていたのですが、どうしても「抜け」や「曖昧さ」が残る感覚があり、手応えが弱い状態が続いていました。 しかし、ワイヤーフレームを作り始めたことで、その状況が一変しました。 この記事では、 ワイヤーフレームがどのようにドメイン設計を補完し、加速させたのかを整理してみます。 ドメイン設計だけでは埋まらない違和感 ドメイン設計を進めていると、以下のような状態に陥ることがありました。 ユースケースはある程度整理されている エンティティや値オブジェクトも定義できている しかし「本当にこれで使えるのか？」という違和感がある つまり、構造はあるが、実感がない状態です。 このとき不足していたのは、「ユーザーがどう操作するか」という視点でした。 ワイヤーフレームを作って起きた変化 試しにワイヤーフレームを作り始めたところ、明確な変化がありました。 1. ユーザーの行動が具体化される ワイヤーフレームでは「画面上で何をするか」を考える必要があります。 どこで入力するのか どの順番で操作するのか 何を確定とみなすのか これにより、ユースケースが単なる文章ではなく、操作として具体化されました。 2. 必要なデータと制約が見えてくる 操作を具体的にすると、自然と以下が見えてきます。 この画面では何のデータが必要か この操作はどんな条件で許されるのか ここで重要なのが、 不変条件（インバリアント） です。 例えば、口座振替管理アプリなら、 支払い元は必ず 1 つである 振替は「元 → 先」の関係を持つ 不正な組み合わせは作れない など、これらはドメイン設計だけでも定義できますが、 ワイヤーフレーム上で「操作」として考えることで、一気に現実味を帯びます。 3. ドメイン設計の「抜け」が露出する ワイヤーフレームを作る中で、次のような気づきが頻発しました。 この状態、どうやって作る？ この操作、どのユースケースに対応する？ このデータ、どこに属する？ つまり、ドメイン設計で曖昧だった部分が強制的に表に出てくるのです。 ...

オブジェクト参照の場合 Order User アプリケーションサービス ID参照の場合 Order User アプリケーションサービス 違いを整理 オブジェクト参照 ID参照 もう一つ重要な違い：イベント駆動に拡張できる Application Service イベントの定義 EventBusの簡易実装 イベントハンドラ ハンドラ登録 イベントの流れ まとめ ドメイン駆動設計（DDD）では、次のようなルールをよく目にします。 集約は他の集約を IDで参照する しかし、初めてこのルールを見たときに疑問が浮かびます。 ID参照にしても結局 Repository.find(id) で取得できるのでは？ それなら普通のオブジェクト参照とあまり変わらないのでは？ この記事では、このルールの意味を 実際のコードで比較しながら説明します。 オブジェクト参照の場合 まず、他の集約を オブジェクトとして直接持つ設計を見てみます。 Order class Order( val id: OrderId, val user: User ) { fun place() { // 注文処理 user.upgradeToPremium() } } tips : place という単語には、 注文を出す / 発注する という意味があります。 User class User( val id: UserId, var plan: Plan ) { fun upgradeToPremium() { plan = Plan.PREMIUM } } アプリケーションサービス fun placeOrder(orderId: OrderId) { val order = orderRepository.find(orderId) order.place() orderRepository.save(order) } ここで起きていることを図にすると次のようになります。 ...

1. 不変条件を同時に守る必要があるか（最重要） 例 別集約になる例 2. ライフサイクルが一緒か 例 別集約の例 3. 集約は他の集約をIDで参照する 4. 同時に更新されるか 例 5. 集約は小さく保つ まとめ ドメイン駆動設計（DDD）で設計をしていると、次のような疑問に必ずぶつかります。 このエンティティは同じ集約に入れるべきか？ それとも別の集約として切り離すべきか？ 集約の境界は、DDDにおいて非常に重要な設計判断です。 この記事では、実務でよく使われる判断基準を整理します。 1. 不変条件を同時に守る必要があるか（最重要） 最も重要な基準は 不変条件（Invariant） です。 「このルールは常に同時に成立している必要があるか？」 YESなら 同じ集約 NOなら 別集約 例 注文と注文明細 Order └ OrderItem 不変条件 注文の合計金額 = 各注文金額の合計 注文明細の数量 ≥ 1 数量が変われば、注文全体の合計金額は変わります。 つまり、これらは 常に同時に成立している必要があります。 そのため Order と OrderItem は 同じ集約になります。 別集約になる例 Order Inventory (在庫) ルール 注文が確定したら在庫を減らす この処理は 注文確定 在庫更新 の2つの処理に分かれます。 これらは 同時トランザクションでなくても問題ないため Order集約 Inventory集約 と分けます。 2. ライフサイクルが一緒か 次に考えるのは ライフサイクルです。 「一緒に生まれて一緒に消えるか？」 YES → 同じ集約 NO → 別集約 例 Order └ OrderItem OrderItem は ...

このドキュメントは、DDD（ドメイン駆動設計）に基づいて、ソフトウェアを設計するためのテンプレートです。 上から順番にテンプレートを埋めていくことで、 DDD に基づいたドメイン周りの設計がスムーズに行えるように作っています。 1. システム概要 システムの目的 対象ユーザー 解決したい課題 2. ユースケース ユースケース一覧 ユースケース詳細 【例】振替関係を作成する 入力 処理概要 出力 3. ユビキタス言語 概念 候補とその言葉のイメージ 賛否の意見 言葉の決定とその採用理由 ユビキタス言語辞書 4. エンティティ候補 5. 不変条件（Invariant） 6. 状態遷移 【例】TransferRelation 状態 状態遷移 7. 集約設計 集約一覧 集約詳細 【例】TransferRelation 属性 不変条件 ドメインメソッド 8. ドメインサービス サービス一覧 サービス詳細 【例】TransferService 9. リポジトリ 10. ユースケース設計 UseCase一覧 UseCase詳細 【例】CreateTransferRelationUseCase 処理 1. システム概要 システムの目的 このシステムは何を解決するものか。 【例】 フリーランスの固定費を管理する 口座振替の関係を可視化する 対象ユーザー このシステムのユーザー。 【例】 個人 フリーランス 企業 解決したい課題 【例】 固定費の支払い関係が分かりにくい 口座振替の全体構造を把握できない 2. ユースケース ユーザーがシステムで行う操作を列挙する。 ...

このドキュメントは、 ドメイン設計テンプレート に以下の項目を加えた補強版となっています。 4.境界コンテキスト 5.コンテキストマップ 7.値オブジェクト 12.ドメインイベント 15.集約境界図 16.不変条件の責任 1. システム概要 システムの目的 対象ユーザー 解決したい課題 2. ユースケース ユースケース一覧 ユースケース詳細 【例】振替関係を作成する 入力 処理概要 出力 3. ユビキタス言語 概念 候補とその言葉のイメージ 賛否の意見 言葉の決定とその採用理由 ユビキタス言語辞書 4. 境界コンテキスト 5. コンテキストマップ 6. エンティティ候補 7. 値オブジェクト 8. 不変条件（Invariant） 9. 状態遷移 【例】TransferRelation 状態 状態遷移 10. 集約設計 集約一覧 集約詳細 【例】TransferRelation 属性 不変条件 ドメインメソッド 11. ドメインサービス サービス一覧 サービス詳細 【例】TransferService 12. ドメインイベント イベント詳細 【例】TransferRelationCreated 発生タイミング ペイロード 13. リポジトリ 14. ユースケース設計 UseCase一覧 UseCase詳細 【例】CreateTransferRelationUseCase 処理 15. 集約境界図（Aggregate Boundary） 【例】TransferRelation 集約名 / Aggregate Root 内部エンティティ 値オブジェクト 集約境界 外部参照 集約ルール 16. 不変条件の責任（Invariant Responsibility） 不変条件一覧 不変条件の責任 振替日は1〜31 同じ口座 + サービスの振替関係は1つだけ 振替関係は必ず口座を持つ 振替関係は必ずサービスを持つ 不変条件の配置ルール 例 1. システム概要 システムの目的 このシステムは何を解決するものか。 ...

DDDにおける「集約」「ドメインサービス」「ユースケース」の違い まず結論 集約（Aggregate） ドメインサービス ユースケース（Application Service） ドメインロジックをどこに置くか 状態を持つドメインサービスはどうなるか ケース1：新しいドメイン概念が生まれた ケース2：一時的な処理状態 判断のための質問 よくある失敗 まとめ DDDにおける「集約」「ドメインサービス」「ユースケース」の違い DDD（ドメイン駆動設計）を学び始めると、多くの人が次の疑問にぶつかります。 集約とドメインサービスは何が違うのか ユースケースはどこまで責任を持つのか ドメインロジックはどこに書くべきなのか この記事では、この3つの概念を整理しながら、ドメインロジックをどこに置くべきかの判断基準を解説します。 まず結論 3つの役割は次のように整理できます。 集約（Aggregate） ドメインの状態を持つ 不変条件を守る ドメインモデルの中心 ドメインサービス（Domain Service） エンティティに属さないドメインロジック 複数の集約にまたがる処理 ユースケース（Use Case / Application Service） ユーザー操作を実現する手順 ドメインモデルを組み合わせる 依存関係は次のようになります。 UI ↓ UseCase ↓ DomainService ↓ Aggregate 重要なルールは 内側の層は外側を知らないこと です。 集約（Aggregate） 集約は 状態と不変条件を守るドメインモデル です。 例として「口座振替」を考えます。 振替関係には次のルールがあります。 振替日は 1〜31 「振替元 + 振替先」が同じ振替関係は 1 つだけ (重複不可) このルールを守る主体が TransferRelation です。 class TransferRelation( val accountId: AccountId, val serviceId: ServiceId, private var paymentDay: PaymentDay ) { fun changePaymentDay(newDay: PaymentDay) { paymentDay = newDay } fun stop() { // 状態変更 } } 【集約の特徴】 ...

DDDでドメインを設計するときの流れ ドメイン設計の全体の流れ この記事の前提 1. ユースケースを書き出す 2. ドメイン用語を整理する（ユビキタス言語） 3. エンティティ候補を出す 4. 不変条件を書く 5. 状態遷移を整理する 6. 集約（Aggregate）を決める 7. エンティティの責務を設計する setterが問題になる理由 ドメインメソッドは「操作」を表す 重要な考え方 8. ドメインサービスを定義する 9. リポジトリを定義する 10. 最後にUIを作る まとめ この流れで設計する際のテンプレート DDDでドメインを設計するときの流れ ― 実践的な設計手順 ― ドメイン駆動設計（DDD）を学び始めると、多くの人が次の疑問を持ちます。 ドメイン設計は何から始めればいいのか 実際の開発ではどのような手順で設計するのか DDDの本では概念の説明が多く、「実際の設計手順」がはっきりしないことがあります。 この記事では、実務で使える ドメイン設計の具体的な手順 を整理して紹介します。 ドメイン設計の全体の流れ DDDでドメインを設計する場合、次の順序で進めると整理しやすくなります。 ユースケースを書き出す ドメイン用語を整理する（ユビキタス言語） エンティティ候補を出す 不変条件を書く 状態遷移を整理する 集約（Aggregate）を決める エンティティの責務を設計する 必要ならドメインサービスを作る リポジトリを定義する 最後にUIを設計する 重要なのは UIから設計を始めないこと です。 DDDでは、基本的には、 ユースケース → ドメイン → UI という順序で設計します。 実際には、一度でバシッと決められるわけではないため、ドメインを設計しているときに、ユースケースに戻るなど、各プロセス間を何度も行ったり来たりします。 この記事の前提 この記事では、口座振替管理アプリの開発を想定して、設計の流れを説明してきます。 振替元と振替先をユーザーが紐づけるメモアプリを想像してください。 1. ユースケースを書き出す 最初に、システムでユーザーが行う操作を書き出します。 ポイントは UIではなく行動を書くこと です。 ...

リファクタリングには二種類ある ― 構造を変えるものと、概念を変えるもの まず整理：構造と概念の違い 構造の変更 概念の変更 なぜこの区別が重要なのか？ なぜ通常は「構造 → 概念」なのか？ ① 変更の安全性 ② デバッグのしやすさ ③ 複雑性の増幅 実務での使い分け（私の優先順位） 第1段階：可視化 第2段階：構造整理 第3段階：責務の明確化 第4段階：概念強化 まとめ リファクタリングには二種類ある ― 構造を変えるものと、概念を変えるもの 私は最近の失敗から、大きな学びを得ました。 それは、 リファクタリングには二種類ある ということです。 構造 を変えるリファクタリング 概念 を変えるリファクタリング この区別を意識していなかったことが、バグの原因でした。 この記事では、自分なりに整理した実務的な優先順位と共にまとめます。 まず整理：構造と概念の違い 構造の変更 関数抽出 共通化 重複削除 名前変更 ネスト解消 責務分離 振る舞いは変えない（意味は同じ） これは「コードの形」を整える作業です。 概念の変更 Boolean → sealed class nullable → 非null設計 エラー型明確化 状態遷移の型化 エンティティ再設計 ドメインモデル再定義 責務の再解釈 プログラムが表現する「意味」が変わる これは「コードが何を表現しているか」を変える作業です。 なぜこの区別が重要なのか？ 私は「成功」という概念を Boolean で扱っていました。 しかし実際には： 作成成功 更新成功 失敗 という複数の意味がありました。 Boolean に押し込めたことで、 意味の差が見えなくなり、無意識に共通化してしまった のです。 ...

Boolean に潰された「成功」 ― リファクタリングで気づいた抽象化の罠 はじめに 元のコード リファクタリングでやったこと 最初は「うっかり」だと思った 本当の原因 抽象化の粒度が粗すぎた 型で守る設計 学び 終わりに Boolean に潰された「成功」 ― リファクタリングで気づいた抽象化の罠 はじめに ViewModel の保存処理をリファクタリングしていたとき、 私は一度コードを壊しました。 原因は単純な「うっかりミス」に見えました。 しかし振り返ってみると、問題はもっと深いところにありました。 それは、 「成功」という概念を Boolean に潰してしまったこと でした。 この記事では、その過程と学びを書きます。 元のコード 保存処理は、新規作成と更新で分岐していました。 private fun saveData() { viewModelScope.launch { val isExistingItem: Boolean = (取得) if (destId == 0) { // 新規作成 val resultSuccess = directDebitDefRepo.createDestination(...) if (resultSuccess) { // フォームの初期化 _formInputState.update { FormInputState() } showSuccess() } else { showFailure() } } else { // 更新 val resultSuccess = directDebitDefRepo.updateDestination(...) if (resultSuccess) { showSuccess() } else { showFailure() } } } } ポイントはここです。 ...

Aggregate Root とは はじめに Aggregate（集約）とは Aggregate Root（集約ルート）とは 具体例（イメージ） 注文ドメインの例 なぜ Aggregate Root が必要なのか ① 整合性を守るため ② トランザクション境界を明確にするため ③ 依存関係をシンプルにするため 設計時の注意点 ① Aggregate を大きくしすぎない ② 他 Aggregate を直接参照しない ③ Repository は Aggregate Root 単位 よくある誤解 まとめ Aggregate Root とは はじめに DDD（Domain-Driven Design）の文脈で頻繁に登場する Aggregate Root（集約ルート） について解説していきます。 本記事では、 Aggregate / Aggregate Root とは何か なぜこの概念が必要なのか 設計時の注意点 を整理します。 Aggregate（集約）とは Aggregate とは、 関連する複数の Entity / Value Object を 一つのまとまり（整合性の境界） として扱う DDD の設計単位です。 重要なのは、 Aggregate は「常に一貫した状態を保つべき単位」 という点です。 ...

SQL の条件を固定しない はじめに 改善前の実装 DAO にドメインの意味が入り込んでいた 問題意識 改善方針 改善後の実装 DAO：検索軸だけを知る Repository / UseCase：意味を与える この設計で得られたメリット 1. SQL / DAO の数が増えにくくなった 2. DAO の責務が明確になった 3. ドメインの変更に強くなった おわりに SQL の条件を固定しない DAO の責務を整理して、ドメインに意味を寄せる設計改善 はじめに Android アプリ開発において、 「とりあえず動く」状態から一段上の設計に進もうとすると、 ViewModel・UseCase・Repository・DAO の責務の境界で悩むことが多い。 今回は、 SQL で条件を固定していた実装を見直し 条件をパラメータ化して SQL の数を減らし その「意味」を Domain / UseCase 側で与える という設計改善を行ったので、その考え方をまとめる。 改善前の実装 DAO にドメインの意味が入り込んでいた もともと DAO には、次のような Query が定義されていた。 @Query("SELECT * FROM transfer_item WHERE isSourceItem = 1") fun observeSources(): Flow<List<TransferItemEntity>> この実装はシンプルで分かりやすいが、次の問題を抱えていた。 DAO が「Source（振替元）」というドメインの意味を知っている 条件が増えるたびに SQL / DAO メソッドが増える 将来的に Query が爆発する兆候がある 問題意識 ここで違和感を覚えたのは、次の点だった。 ...

「サービスクラス」とは何か？ 「サービス」という言葉の語源と基本ニュアンス Web / サーバーサイドでの Service クラスの起源 なぜ「サービスクラス」が問題視されるようになったのか DDD における「Service」との分岐 UseCase は何に対するアンチテーゼなのか Web エンジニアが「サービスクラス」と言うときの意味 1. 中立的な意味 2. 否定的な意味（設計議論） まとめ 「サービスクラス」とは何か？ ──語源・ニュアンス・UseCaseとの違いを整理する 設計の議論をしていると、「それ、サービスクラスじゃない？」という言葉が出てくることがある。 一方で、Web エンジニアの中には「Service クラス」は普通に使う用語だ、という人も多い。 この「サービスクラス」という言葉は、厳密な定義がなく、文脈によって意味が変わるため、混乱を生みやすい。 この記事では、語源と歴史をたどりながら、 なぜ「サービス」と呼ばれるのか Web ではどのように使われてきたのか なぜ設計議論では否定的に使われることがあるのか UseCase と何が違うのか を整理する。 「サービス」という言葉の語源と基本ニュアンス 英語の service は、 奉仕 提供 役務 といった意味を持つ。 ソフトウェア設計においては、そこから転じて、 「他のオブジェクトのために処理を提供するもの」 という、かなり広い意味で使われるようになった。 この時点では、「サービス」はあくまで 役割を説明するための便利な言葉であり、設計上の厳密な概念ではない。 Web / サーバーサイドでの Service クラスの起源 「サービスクラス」という言葉が広く使われるようになったのは、 Java EE や Spring に代表される レイヤードアーキテクチャの文脈である。 典型的な構成は以下のようなものだ。 Controller ↓ Service ↓ Repository (DAO) ここでの Service クラスは、 Controller から呼ばれる 複数の Repository を組み合わせる トランザクション境界になる 業務ロジックを書く場所 という役割を担っていた。 ...

ViewModel が肥大化する理由 よくある誤解：ViewModel は「中継役」だから重くなる ViewModel が肥大化する本当の理由 「UI の判断」と「業務の判断」は別物 UseCase が登場する理由 ViewModel と UseCase の境界線 「ViewModel から処理がほとんど消えそう」問題 まとめ ViewModel が肥大化する理由 Android アプリを作っていると、ある日ふと気づきます。 ViewModel、でかくなりすぎじゃない？ State の定義、Flow の合成、エラーハンドリング、変換ロジック、画面固有の分岐……。 気づけば 1 ファイルに数百行。しかも「どこを直すと何が壊れるのか分からない」状態。 この記事では、なぜ ViewModel は肥大化しやすいのか、そして それを防ぐための本質的な境界の引き方 について整理します。 よくある誤解：ViewModel は「中継役」だから重くなる よく言われる説明に、こんなものがあります。 ViewModel は UI と Domain の橋渡しだから Flow や State を扱うから 非同期処理が集まりやすいから どれも一理ありますが、本当の理由ではありません。 Flow があるから肥大化するのではなく、 ViewModel が 本来持つべきでない判断 を持ち始めたときに肥大化します。 ViewModel が肥大化する本当の理由 結論から言うと理由はシンプルです。 「何をするか」を ViewModel が決め始めるから 本来の ViewModel の役割は、次の 2 つです。 UI からのイベントを受け取る UI が描画しやすい State に変換して公開する ところが実際には、次のような責務が入り込みがちです。 ...

Domain と UseCase の違いを整理してみる 一言で言うと何が違うのか Domain とは何か Domain は「意味」と「ルール」の集合体 Domain の例 Domain がやらないこと UseCase とは何か UseCase は「動詞の層」 UseCase の例 Domain と UseCase の関係 なぜ UseCase が分かりにくいのか UseCase を作るべきタイミング Entity → Domain 変換はどこでやるべきか Domain と UseCase を分ける最大のポイント よくあるアンチパターン おわりに Domain と UseCase の違いを整理してみる Clean Architecture や DDD を学んでいると、ほぼ確実に次の疑問にぶつかります。 Domain と UseCase の違いがよく分からない どこまでが Domain で、どこからが UseCase なのか曖昧 UseCase を作ろうとすると、何を書けばいいのか分からない 私自身、このあたりで何度も立ち止まりました。 この記事では、実装経験を通して整理できた Domain と UseCase の違い を、自分なりの言葉でまとめてみます。 一言で言うと何が違うのか まず、かなり大胆に要約します。 Domain →「この世界では、何が正しく、何が成り立つか」を表す UseCase →「その正しさを、どういう手順・文脈で使うか」を表す ...

Domain レイヤーかどうかを判断する基準 Domain レイヤーとは何か（簡単に） 判断基準：ユーザーがそれを意識するか？ 例1：保存処理は Domain か？ ケースA：保存先をユーザーが意識しない場合 ケースB：保存先をユーザーが意識的に選択する場合 「ユーザーが意識する」という基準の使いどころ UseCase との関係 注意点：すべてを Domain に入れない 迷ったときの最終チェック おわりに Domain レイヤーかどうかを判断する基準 ―「ユーザーが意識するか？」という視点― 設計をしていると、次のような悩みにぶつかることがあります。 この処理は Domain レイヤーに置くべきか？ UseCase なのか、それとも Data レイヤーの責務なのか？ そもそも Domain って何を置く場所なのか？ とくに Clean Architecture や DDD を学び始めた頃は、 「正解の置き場所」を探そうとして、かえって混乱しがちです。 この記事では、私が設計を考える際に ひとつの判断基準 として使っている考え方を紹介します。 Domain レイヤーとは何か（簡単に） Domain レイヤーは、ざっくり言うと アプリが扱う 概念 その概念に関する ルール 「それは正しいかどうか」の判断 を表す層です。 技術的な詳細（DB、API、ライブラリなど）からは距離を置き、 アプリの意味そのもの を表現する場所だと考えています。 判断基準：ユーザーがそれを意識するか？ 私が Domain レイヤーかどうかを判断する際に使っている基準は、次の問いです。 「ユーザーは、その機能や概念を意識してアプリを操作するか？」 この問いに YES なら、 その概念や処理は Domain レイヤー（または UseCase）に属する可能性が高いです。 NO なら、 それは Data レイヤーや Infrastructure に閉じ込めるべきものだと考えます。 ...

設計不良なソフトウェアの現場で起きていること 影響範囲が見えないまま進む実装 ここで言う「影響範囲がわからない」とはどういう状態か 実装完了後に始まる、本当の消耗戦 なぜこの状況は繰り返されるのか エンジニアは「疲れたから」辞めているわけではない 設計の役割は「人間が判断できる状態」を作ること 消耗戦を終わらせるために 設計不良なソフトウェアの現場で起きていること 設計不良なソフトウェアの現場では、共通して起きることがあります。 変更を入れようとすると、「どこまで影響するのか分からない」という声が上がる。 それでも、プロジェクトは止まりません。 スケジュールは既に決まっている 調整は簡単には認められない 技術的制約を解消するための時間も取れない 結果として、「今の構造のまま、なんとか実装してほしい」という判断が下されます。 この時点で、プロジェクトはすでに消耗戦に入り始めています。 影響範囲が見えないまま進む実装 影響範囲が分からない状態では、エンジニアは慎重になります。しかし、慎重に考えれば考えるほど、時間は足りません。 安全に直したい でも期限がある 設計を整理する余裕はない その結果、選ばれるのは「期限内に動く可能性が高そうな実装」です。 設計的には無理があると分かっていても、他に選択肢がないため、応急処置的な実装が積み重なっていきます。 ここで言う「影響範囲がわからない」とはどういう状態か ここで、この記事で使っている「影響範囲がわからない」という言葉の意味を、少しだけ整理します。 これは単に、 調査が足りない エンジニアの理解が浅い という話ではありません。 影響が 大きすぎて、複雑すぎて、人間の脳の仕組み的に追いきれない という状態を指しています。 どこを変更すると、 どの画面に どの機能に どの状態に 影響するのか。 それを一人のエンジニアが頭の中で安全にトレースできない。これが「影響範囲が見えない」状態です。 実装完了後に始まる、本当の消耗戦 スケジュール上は、実装は一度「完了」します。しかし、その後に不具合が多発します。 影響範囲を把握できないまま実装している以上、これはほぼ必然です。 想定外の画面で不具合が発生する 特定の操作順でのみ再現するバグが出る 修正すると別の箇所が壊れる 不具合対応という 予定外の作業 が発生し、本来進めるはずだったタスクは後ろ倒しになります。 エンジニアは長時間労働になり、管理者はスケジュールを組み直すことになります。 誰も得をしません。 なぜこの状況は繰り返されるのか この問題は、エンジニアの努力不足ではありません。むしろ、責任感の強いエンジニアほど無理をします。 しかし、 影響範囲が見えない設計 技術的負債を返すための時間や構造がない これが変わらない限り、結果も変わりません。 エンジニアは「疲れたから」辞めているわけではない 長時間労働が続くと、「エンジニアが疲れて辞めた」と説明されがちです。 しかし実際には、 頑張っても状況が改善しない 技術的負債が解消される兆しが見えない 消耗戦が続く未来が想像できてしまう こうした 構造的な行き止まり を感じた結果として、プロジェクトを抜ける決断をしているケースが多いのではないでしょうか。 エンジニアが定期的に入れ替わる現場では、個人の忍耐力やモチベーションではなく、 影響範囲が見えない設計が放置されていないか 技術的負債を解消するための構造や仕組みが存在するか といった点を、疑うべきだと考えます。 設計の役割は「人間が判断できる状態」を作ること 設計の役割は、コードを綺麗にすることではありません。 ...

ソフトウェア設計が分かっていても、 Android アプリが作れない理由 Android アプリの設計は「掛け算」で成立する Android OS 固有の制約 Kotlin を「使っている」と「使いこなしている」の差 Jetpack Composeは「 UI 実装」ではなく「設計そのもの」 「設計思想 × Android 文脈」が価値になる 自分の強みについて ソフトウェア設計が分かっていても、 Android アプリが作れない理由 ソフトウェア設計が分かっている人が、必ずしも Android アプリをうまく作れるとは限らない。 これは、 Android 開発を続けてきて、何度も実感してきたことだ。 設計原則を理解している。 責務分離の重要性も分かっている。 それでも、 Android アプリとして形にしようとすると、どこかで無理が出る。 その理由は、単に Android OS の制約が強いから、というだけではない。 Android アプリの設計は「掛け算」で成立する Android アプリの設計は、次の要素が同時に成立して初めて機能する。 Android OS 固有の制約 Kotlin という言語の前提 Jetpack Compose という UI モデル どれか一つだけ分かっていても足りない。 Android OS 固有の制約 まず避けて通れないのが、 OS の制約だ。 ライフサイクルが複雑で、いつ破棄されるか分からない プロセスは OS 都合で突然 kill される バックグラウンド動作や権限には厳しい制限がある これらを無視した「きれいな設計」は、実機上では簡単に崩れる。 Android では、 壊されることを前提に設計する 必要がある。 ...

当時のプロジェクト状況 技術的には明らかに課題が見えていた それでも、抜本的な改善をしなかった理由 私が選んだ技術的判断 この経験から学んだこと 当時のプロジェクト状況 以前関わっていたプロジェクトは、多重下請け構造になっており、私自身は二次受け企業と業務委託契約を結んでいました。チーム内には三次受け、二次受け、一次受けのメンバーが混在しており、Android のテックリードは一次受け企業に一人だけという体制でした。 そのテックリードは複数チームを横断して担当しており、勤務地も異なっていたため、1年間一緒に仕事をしたにもかかわらず、対面どころかオンライン会議で直接会話したこともありませんでした。技術的な判断は基本的にその方に集約されており、私は設計の最終決定を主導できる立場ではありませんでした。 技術的には明らかに課題が見えていた コードベースを見ていて、技術的な課題は比較的はっきりしていました。ホーム画面に相当する Activity は肥大化しており、多くの責務を抱え込んでいました。Fragment に分割することで、見通しや保守性が大きく改善できる状態だったと思います。 また、ドメインロジックやユースケースは一応共通化されていたものの、副作用が多く、どこかを修正すると別の箇所に影響が出やすい構造になっていました。本音を言えば、設計を見直し、腰を据えて整理したいと感じる場面は何度もありました。 それでも、抜本的な改善をしなかった理由 ただ、そのような改善は、実装者一人の判断で進められるものではありませんでした。Fragment 分割やドメイン設計の見直しは影響範囲が広く、他社のテックリードとの合意形成が前提になります。 さらに当時は、設計以前に対処すべき問題が数多く存在しており、プロジェクト全体として常に余裕がない状況でした。その中で大きな構造変更を提案し、進めることは、技術的には正しくても、プロジェクトとしてはリスクが高いと感じていました。 「重要だと分かっているからこそ、今はやるべきではない」 そう判断せざるを得ない状況だったと思います。 私が選んだ技術的判断 最終的に私は、抜本的な構造変更は行わないという判断をしました。その代わり、既存の設計を前提としたうえで、自分が責任を持てる範囲に改善を限定し、変更による影響を最小化することを重視しました。 ここでの判断は、「何を実装するか」ではなく、「何をやらないかを決めること」だったと捉えています。設計を理想形に近づけることよりも、プロジェクト全体を不安定にしないことを優先しました。 この経験から学んだこと この経験を通じて、技術的な判断はコードの中だけで完結するものではないと強く感じるようになりました。設計の正しさだけでなく、その設計を実行できる組織構造や権限、合意形成のコストまで含めて考える必要があります。 良い設計を思いつくことと、それを実際に推し進められることは別の話です。その違いを理解し、今やるべきことと、あえてやらないことを切り分けることも、エンジニアの重要な役割だと思っています。 技術判断は、コードの外にもある。このプロジェクトは、そのことを強く意識するきっかけになりました。

なぜクリーンアーキテクチャはドメインを守るのか はじめに 不変条件とは何か 例 不変条件は「判断」そのものである 不変条件が曖昧だと、設計は壊れる 不変条件をドメインに閉じ込める、という判断 なぜドメインなのか 「ドメインを守る」とは、何を守っているのか UI やインフラに不変条件を置くと何が起きるか まとめ おすすめの関連書籍（無料） なぜクリーンアーキテクチャはドメインを守るのか クリーンアーキテクチャはドメインを守っているが、その本質は「判断」を守ることである はじめに 「クリーンアーキテクチャでは、ドメインを守ることが重要だ」 この説明を、これまで何度も目にしてきましたし、自分でも何となく理解しているつもりでした。 UI から独立させるため フレームワークに依存させないため テストしやすくするため どれも間違ってはいません。 ただ、実務で設計に向き合えば向き合うほど、 それで結局、何が一番大事なのか？ という疑問が残りました。 最近、その答えが少しはっきりしてきました。 クリーンアーキテクチャの本質は、 「判断をどこに閉じ込めるか？」を決める構造である という考え方です。 どの判断は UI に任せてよいのか どの判断はユースケースで行うべきか どの判断は、絶対に外に漏らしてはいけないのか この「判断の置き場所」を曖昧にしたまま設計すると、 責務が混ざり 修正のたびに迷いが生まれ 変更に弱い構造 になっていきます。 では、 絶対に外に出してはいけない判断とは何なのか？ その答えを整理するための言葉が、不変条件 でした。 （不変条件という言葉は、英語では invariant という言葉でよく使用されます） この記事では、 クリーンアーキテクチャを「判断の置き場所」という視点で捉え直し その中で不変条件がどんな役割を持つのか なぜ不変条件をドメインに閉じ込めるのか を、実務の感覚に近い形で説明します。 不変条件とは何か 不変条件とは、 どれだけ仕様や実装が変わっても、絶対に破ってはいけない前提 です。 UI が変わっても API が変わっても DB が変わっても これが壊れたら、そのシステムは成立しない そういう条件を指します。 例 ログインしていないユーザーは、保護された操作をできない 残高は常に 0 以上である 同じ支払いは二重に確定しない これらは ...

アーキテクチャとは 依存関係とは 物理的な依存関係 意味的な依存関係 ドメインとは ドメイン以外 同心円状の図の意味 意味的な依存関係とクリーンアーキテクチャ 具体例 依存関係の逆転が必要なケース 依存関係を逆転させる具体的な方法 おすすめの記事 おすすめの本（無料） クリーンアーキテクチャという言葉はよく聞くけれど、「わかったようでわからない」という人が多いのではないでしょうか？ クリーンアーキテクチャを解説した記事は、探せばすぐに出てきますが、あまり本質について語られている記事は少ないように感じます。 そこで、この記事でそれを簡潔に語っていこうと思います。 アーキテクチャとは まず、そもそも「アーキテクチャ」とは何でしょうか？簡潔に説明したいので、どんどん答えを書いていきます。 目的 壊れにくいソフトウェアを作る チーム内で統一した方針でソフトウェアを作る 実現方法 部品 (※1) 同士の依存関係 (※2) を整える 部品が果たす役割・責務を明確にする (※1) 「部品って具体的に何？」と思われた方は、一旦、クラスだと思っていただければ大丈夫です。 (※2) 後述します。 めちゃくちゃシンプルに書くとこうなると思います。 依存関係とは クリーンアーキテクチャの本質を知るためには、このセクションがめちゃくちゃ大事です！！ 「そんなの知ってるわ」という方も、クリーンアーキテクチャについての理解が「モヤッ」としている方は読んでください。 依存関係には、二種類の依存関係があります。 物理的な依存関係 まずは、物理的な依存関係について説明します。これは、多くの人が最初に思い浮かぶ依存関係の方だと思われます。 すなわち、「どの部品 (クラスなど) がどの部品のことを知っているか」という関係性のことです。 (このドキュメントのサンプルコードは Kotlin で記述させていただきます。ご了承ください。) class A { val b: B } class B { // ... } 上記のサンプルでは、クラス A がクラス B を知っているので、これを「 A が B に依存している」と言います。 これが、物理的な依存関係です。 (超ざっくり) 意味的な依存関係 次に、意味的な依存関係について説明します。ここで、クリーンアーキテクチャの記事でよく出てくる同心円状の図を見て下さい。 (探せばすぐに出てくるのでここには載せません。笑) ...

Zenn で記事を書いていましたが、長期的な執筆活動を見越して、 Hugo + GitHub Pages で、技術ブログを始めることにしました。 このブログでは、 Android / Jetpack Compose 設計・アーキテクチャ 技術的な意思決定（ADR） について書いていきます。