はじめに
なぜ「再読」なのでしょうか。以前にも『Clean Architecture』を一度読みましたが、その頃は実際のプロジェクトで経験を積み、試行錯誤する機会が少なく、理解が浅いと感じていました。その後、仕事でいくつかのプロジェクトや要件に取り組む機会に恵まれました。さらに幸運なことに、チームが採用していたのはクリーンアーキテクチャで、詳しく言えばイベント駆動開発のDDDとクリーンアーキテクチャを組み合わせたものでした。DDDの詳細は後で取り上げます。そこで本書📚を読み直したところ、多くの学びがありました。このシリーズでは、私なりの理解でクリーンアーキテクチャについて説明します。より正確には読書ノートとして、同じ分野に携わる方々と共有したいと思います。
本書の詳細はこちらです：『Clean Architecture』—ロバート・C・マーティン—微信読書（qq.com）
このシリーズでは本書の章立てに沿い、著者とともに理解を深めていきます。ただし再読なので、後の章の内容に触れることもあります。読んでいて理解しづらい内容や初めて聞く言葉が出てきたら、おそらく後の章で説明されるものです。
それでは始めましょう。
設計とアーキテクチャの意味
設計とアーキテクチャに本質的な違いはありません。低レベルの設計の詳細と高レベルのアーキテクチャの情報が、一体となってソフトウェアシステムを定義します。
ソフトウェアアーキテクチャの究極の目標は、システムの構築と保守の要件を最小限の人的コストで満たすことです。したがって、コストはソフトウェアアーキテクチャの設計の良し悪しを評価する指標になります。
設計を十分に行わず急いで構築したシステムは、混沌としたシステムになりかねません。このようなシステムでは、構築の過程でコード品質や設計構造の改善が長期間にわたって軽視されています。アーキテクチャを丁寧に設計することで、システムが混沌に陥ることをある程度防ぎ、コストを抑えられます。
ソフトウェア開発には、次の二つの重要な特徴があります：
- 速く進むには、まず安定して進むこと。
- 過信すると、設計のやり直しでも元のプロジェクトと同じ行き詰まりに陥ること。
二つの価値の側面
ソフトウェアシステムには、二種類の価値があります：
- 振る舞いの価値：指定された方法で機械を動作させ、システムの利用者に利益をもたらす、または利益を増やすこと。
- アーキテクチャの価値：ソフトウェアが十分に柔軟であり、変更のコストが要件の範囲に依存し、その形には依存しないこと。
要件の「範囲」と「形」は、どう理解すればよいのでしょうか。 私の理解では、範囲とは要件のおおまかな対象範囲と、それが属するドメインを指し、形とは要件の具体的な内容を指します。
では、どちらの価値がより重要なのでしょうか。 著者は、次の理由からアーキテクチャの価値のほうが重要だとしています：
- 正常に動作していても変更できないプログラムは、要件が変わると正常に動作しなくなります。変更して再び動かすこともできないため、その価値は0になります。
- 現在は正常に動作しなくても、簡単に変更できるプログラムなら、修正することも、要件の変化に合わせて継続的に変更することも容易なはずです。したがって、そのプログラムは価値を生み続けます。
事業部門と開発部門が共通して犯しがちな誤りは、本当に緊急かつ重要な機能と、緊急ではあっても重要ではない機能を区別しないことです。その結果、重要なシステムアーキテクチャの問題が、重要ではない振る舞いの機能に道を譲ってしまいます。
システムアーキテクチャの重要性と機能の緊急性を調整することは、ソフトウェア開発者自身の責任です。
筆者注：開発者同士でも、チームが異なれば似た問題が起こります。たとえば、バックエンドは一連のAPIを提供するだけなので簡単だと考え、適切な設計の重要性を理解していないフロントエンド部門もあります。
良いソフトウェアアーキテクチャのために戦い続けよう✊
ソフトウェアアーキテクチャの価値を軽視すると、システムは次第に保守が難しくなり、やがて変更できなくなります。そうなったなら、開発チームは要求を出す側と十分に議論せず、果たすべき責任を果たさなかったということです。