BSA
Creating Layered Bussiness Architectures †
成功するプロジェクトは同時にすべてのレイヤーを開発することは滅多にない。
成功するプロジェクトの多くがスパイキングと呼んでいるプロセスにしたがって開発している。
スパイクとはターキテクチャのレイヤーまたはサブシステムの関連するものすべてを実装した機能からユーザから見える部分のことだ。
スパイクのキーとなる性質はすべてのサブシステムの機能のいくつかの特定の側面から駆動することだ。（私は2つのサブシステムを接続することを釘と呼んでいる）
スパイクは反復的な開発をするアプローチだ。
最初のスパイクはアーキテクチャの基本を作り出し、リスクマネージメントの実践的な基本になるので、意図すべきシステムを準備するためにホワイトボード上で改善する余地はある。
スパイクが追加されることによって、システムはもっと安定する。
スパイクはまたすべてのレイヤーを通したスパイク駆動が熟練されることによって、もっと早く得ることができる。
すべて会社にとって、特定のシステムの機能が時間をかけて実装されたとしても利益がある。
チームがどこから開発を始めていいかわからない場合には、サービスレイヤーかユーザインターフェースから始めてみよう、それが8-2図の上半分だ。
8-2図の上半分はサービスレイヤーから作業を始めて、その成果をユーザインターフェースに反映させるアプローチだ。
多くのプロジェクトにおいて、サービスレイヤーはユーザインターフェースチームがサービスレイヤーの成果物を使って作業する前に、実装を完了すべきでない。
多くの場合ダミーデータを返すサービスレイヤーは生きたデータソースと接続されたサービスよりも役に立つだろう。
なぜなら、ダミーデータと共に素早く段階を移行できるからだ。
筆者はサービスレイヤーを定義することを重要視する。
なぜなら、サービスインターフェースを正しく得ることは残りのターキテクチャ正しくを作り出すよりずっと容易だからだ。
もしサービスインターフェースが悪いとプロジェクトにとってリスクになる。なぜならそれは後に結局修正しないといけなくなるからだ。
もっと大事なことに、もしイテレーティブな実装モデルを実践しているならば、既存のサービスの後に追加のサービスの基礎を構築しようとすることが多い。
もっとシンプルにするなら、少しのサービスを開発した後に、将来のサービスは同じスタイルを使用した開発となることが多い。
アジャイルな開発方法、例えばスクラムやXPは特にこれらのスパイクを使うことだろう。なぜなら、それらはフィードバックループを提供するようデザインされているからだ。
レイヤー化されたアーキテクチャを構築する他の方法が多くある。
他の方法としては8-2図の下半分に書かれているもので、チームは実在の量のデータが必要な時か、永続化ストレージが極端に必要とされる場合には、データベースのデザインから始め、そのデザインをサービスやドメインレイヤーに反映させることが安全だろう。
複雑な永続ストレージの要求と複雑なドメインモデルの間には関連性がある。
プロジェクトの後半でサービスレイヤーの上にユーザインターフェースが置かれる。
もし十分なリソースがあるなら、複数のレイヤーは分割しておくことができる。
このアプローチの鍵はアーキテクチャの核となるサブシステムを早期に確立することだ。
これはプロジェクトの早期の開発段階でサブシステムのインターフェースを完成させることによって達成され、毎日または毎週の構築でサブシステムが更新されることを保証するためにしたほうがいい。
もしパラレルな開発を試みるなら、開発チームはレイヤーが他のレイヤーから影響されることに賛成していることを確かめるべきだ。
最初に行うべきことは、セオリではサービスかドメインのどちらかのレイヤーにすべきだ。これはすべてを正しく得られることを意味していない。ただどこから始めるかの方法が一致しているだけだ。
不運なことに、すべてのレイヤーにとって他のレイヤーをキャッチアップするための待ちが存在するだろう。
筆者は2つのステージのプロセスで働くことがベストだとわかった。
まず最初にドメインレイヤーが必要な変更を作成し、サービスレイヤーがユーザインターフェースへのサポートをするための変更や、インメモリデータベースを通したデータベースモデルへの変更を許可する。
これはユーザインターフェースチームが作業を進めることを許可するし、ドメインチームがアプリケーションへの変更を評価することを可能にする。
この現象が起こっているいる間、データベースチームは彼らの変更ができる。この現象が終わったら、ドメインはデータベースレイヤーと接続され、すべてのアプリケーションが動作する。とにかくリスクを減らすためにできるだけアーキテクチャを固定すべきなのだ。
コラム: すべてのレイヤーをスパイク †
筆者が上記で述べたアプローチは実際のプロジェクトを単純化したものだ。
レイヤーアーキテクチャを構築するすべてのチームはチームが置かれた特有の環境と固有の環境を考慮すべきだ。
実際には、これが意味することはキーとなるリスクを管理し、取り組む方法でスパイクの計画が作成されなけばならない。
大事なことは、スパイクが管理されていること、なぜなら、チームはシステムのすべてのレイヤーを通して機能的に"pushing"されるからだ。
筆者がスパイクを使用して大きな成功したことあるので、開発チームがアプリケーションのすべてのレイヤーを含んでいない時に筆者はがっかりする。
一つのクライアント/サーバシステムでは、サーバチームがクライアント側を含まないスパイクプランを作成した時に、問題を抱えることがあった。
サーバチームは自分たちのサーバを作成した。それは3つのレイヤーアーキテクチャのモデル（サービス、ドメイン、データベース）からなり、クライアント側がことアーキテクチャのインターフェースを必要としていることを忘れていた。
筆者達がこのモデルの上にクライアント側のユーザインターフェースをおいた時、チームは簡単に解決されたであろういくつかの問題を認識して、チームはすべてのレイヤーをスパイクさせるようになった。
担当者のつぶやき †
みんなの突っ込み †
