アーキテクチャ
問題
通常、アーキテクチャについての議論は、プロジェクトの開発が何らかの問題で停滞しているときに持ち上がります。
バスファクターとオンボーディング
プロジェクトとそのアーキテクチャを理解しているのは限られ た人々だけです。
例:
- 「新しい人を開発に加えるのが難しい」
- 「問題があるたびに、各自が異なる回避策を持っている」
- 「この大きなモノリスの中で何が起こっているのか理解できない」
暗黙的かつ制御されていない結果
開発やリファクタリングにおいて多くの暗黙的な副作用が発生してしまいます（「すべてがすべてに依存している」）。
例:
- 「フィーチャーが他のフィーチャーをインポートしている」
- 「あるページのストアを更新したら、別のページのフィーチャーが壊れた」
- 「ロジックがアプリ全体に散らばっていて、どこが始まりでどこが終わりかわからない」
制御されていないロジックの再利用
既存のロジックを再利用したり修正したりするのが難しいです。
通常、2つの極端なケースがあります。
- 各モジュールごとにロジックを完全にゼロから書く（既存のコードベースに重複が生じる可能性がある）
- すべてのモジュールを
sharedフォルダーに移動し、大きなモジュールの「ごみ屋敷」を作る（ほとんどが一箇所でしか使用されない）
例:
- 「プロジェクトに同じビジネスロジックの複数の実装があって、毎日その影響を受けている」
- 「プロジェクトには6つの異なるボタン/ポップアップコンポーネントがある」
- 「ヘルパー関数の「ごみ屋敷」」
要件
したがって、理想的なアーキテクチャに対する要求を提示するのは、理にかなっています。
注記
「簡単」と言われるところでは、「広範な開発者にとって相対的に簡単である」という意味です。なぜなら、すべての人にとって完璧な解決策を作ることはできないからです。
明示性
- チームがプロジェクトとそのアーキテクチャを簡単に習得し、説明できるようにする必要がある
- 構造はプロジェクトのビジネス価値を反映するべきである
- 副作用と抽象化間の関係が明示されるべきである
- ユニークな実装を妨げず、ロジックの重複を簡単に発見できるようにする必要がある
- プロジェクト全体にロジックが散らばってはいけない
- 良好なアーキテクチャのためにあまりにも多くの異なる抽象化やルールが存在してはならない
制御
- 良好なアーキテクチャは課題の解決や機能の導入を加速するべきである
- プロジェクトの開発を制御できる必要がある
- コードを拡張、修正、削除するのが簡単であるべきである
- 機能の分解と孤立性が守られるべきである
- システムの各コンポーネントは簡単に交換可能で削除可能であるべきである
- 未来を予測することはできないから、変更に最適化する必要はない
- 既存のコンテキストに基づいて、削除に最適化する方が良い
適応性
- 良好なアーキテクチャは、ほとんどのプロジェクトに適用可能であるべきである
- 既存のインフラソリューションと共に
- どの発展段階でも
- フレームワークやプラットフォームに依存してはいけない
- プロジェクトとチームを簡単にスケールアップでき、開発の並行処理が可能である必要がある
- 変化する要件や状況に適応するのが簡単であるべきである