「エンジニアはまずアーキテクチャの全体像から始めるべき」、というのが先人たちの知恵からの教訓となっています。
...
アーキテクチャの計画は、皆を安心させてくれます。なぜなら、それはいかにも計画らしく見えるからです。
...
残念なことに、このような壮大な計画は往々にして技術的負債につながり、完全な静止状態に向かって崩壊します。システム内のサービスにたった１つ複雑なものがあるだけで、プロジェクト全体がだめになることがあります。新しい計画に、初期段階で不明な問題点を容易に組み込むことはできません。なぜなら、全てのサービスはこのアーキテクチャの契約によって決まっているからです。
簡単に言えば、アーキテクチャの計画は、チームにウォーターフォール開発を強いるのです。このシステムにより、失敗したプロジェクトがどんどん増えています。
ユーザストーリーとは、ソフトウェアを使う人の視点から語られるシンプルなシナリオです。
...
アプリケーションは、ユーザのタイプに合わせた機能を作るこのような小さなシナリオから始めるべきです。
ソフトウェアデザインとは、コードを小さいモジュール単位に分割した状態で管理し続けるための規則であると考えてください。
...
ここでモジュールをレンガだと考えます。レンガには、1つずつ分離している性質と自由に組み合わせることができる性質があるので、擁壁、住宅、宮殿など、あらゆる建築物を築くためによく使われます。小さいモジュールを集めて、大きなモジュールにすることができます。複数のモジュールをまとめると、サービスになります。
ソフトウェアデザインに注力する場合、アーキテクチャの構築プロセスは避けて通れません。アーキテクチャマップからサービスやコードにドリルダウンするのではなく、私たちはコードからアーキテクチャを構築するアプローチを提唱します。このアプローチには、次に示す通り、大きな利点が2つあります。
- コードやプロダクトから抽象化を進めたものなので、どこか高いところから押し付けられたものよりも実情を的確に表現できる。
- コードのモジュールは分離していて、必要に応じて再編成することができる。
ソフトウェアを構築する場合によくあることですが、私たちエンジニアは、単純なものを作成していると、どうせすぐに機能を追加しなければならなくなるのだろうな、と想像します。そして賢明にも、そういった機能を直ちに作ることが多いのです。
...
こうした経緯の常として、追加された機能によって コードは複雑になり、作業効率が下がります。すると不具合が増加し、処理速度が低下します。不具合のためにパフォーマンスやセキュリティが低下することは多く、目的とは正反対の結果となります。
成長し、生きているソフトウェアプロジェクトは、事前に適切な抽象化をすることはできません。そのような推測こそ、私たちがお勧めしない「事前の最適化」です。最適化が可能なパターンが現れるまで待ち、リファクタリングしましょう。
いくつかの既定事項のために、私たちはアーキテクチャを最初に考えなければなりません。言語とフレームワークは、チームにおける文化および最上の人材を補充する能力に影響してきます。モダンで、オープンソースで、十分なサポートを受けられる言語とフレームワークを選んでください。データベーステクノロジはアダプタ層と一緒に抽象化されますが、それでもあなたのニーズとあなたの選択が暗に意味するものを慎重に考慮することは重要です。
アーキテクチャよりもデザインを優先することは、チームにとって、問題に対してアウトサイドインのアプローチで取り組むことを余儀なくされる、パラダイムシフトです。このアプローチの有利な点は、チームでシステムの全箇所を連携させて動かそうという時に、直前の統合作業のステップが必要ないことです。アーキテクチャよりデザインを優先させると勝てるのは、プロジェクトリスクが減るからなのです。