Android

ソフトウェア設計が分かっていても、 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 に依存している」と言います。 これが、物理的な依存関係です。 (超ざっくり) 意味的な依存関係 次に、意味的な依存関係について説明します。ここで、クリーンアーキテクチャの記事でよく出てくる同心円状の図を見て下さい。 (探せばすぐに出てくるのでここには載せません。笑) ...