@kawasimaさんのアーキ部「Grokking Simplicity探訪」を拝聴した
その時のスライド www.slideshare.net
内容は「Grokking Simplicity」という本で書かれている「Stratified Design」の紹介が主
Grokking Simplicityは以前読んでいてブログに書いていたので内容は把握しているが、kawasimaさんによる説明により、より深い理解につながってよかった uga-box.hatenablog.com
Stratified Design の Stratifiedは直訳すると層別になるが、同じ意味を持つレイヤードアーキテクチャとどう違うのかというと
元々の意味は同じかもしれないが、伝統的なレイヤードアーキテクチャは次のようなレイヤー分けを指しているが多い
WEB層
↓
アプリケーション層
↓
ドメイン層
↓
データアクセス層
ただ、本来のPOSA（Pattern-Oriented Software Architecture）のレイヤードアーキテクチャは同じ抽象度のコンポーネントをグルーピングするとあるので、よくよく考えるとこのレイヤー分けは抽象度の階層になってない
ということで、以下のようなクラスを作って満足しないで
- xxxController
- xxxService
- xxxRepository
ちゃんと抽象度階層別に分けようよ、というのがStratified Design
抽象とは？
抽象とは目的と手段の関係にあるもの、手段は目的になりうるのでフラクタル構造になる
目的①
┌──┼──┐
手段 手段 手段かつ目的②
┌─────┼──────┐
目的②の手段 目的②の手段 目的②の手段
Stratified Designではこの目的（ブランチノード）と手段（リーフノード）の関係において、詳細な実装を持たせるのはリーフだけにして、ブランチノードは詳細な実装を持たず、その機能だけで実装が実現できない場合は、下のレイヤーに手段を委譲してそれを組み合わせる手法になる
これにより、似た責務を持つ要素をグループ化することになるので理解しやすさと保守性を高めることができる
これまでの伝統的なレイヤードアーキテクチャのやりづらさ
Stratified Designではできるだけ下のレイヤーに依存しないリーフに切り出すのが良いとされる
これはkawasimaさんの過去のアーキ部で「ドメインモデルの完全性と純粋性はトレードオフである」という内容の話があったが、これに照らし合わせると
純粋性に当たるという
ドメインモデルの完全性と純粋性のトレードオフについてはこちらにまとめてある uga-box.hatenablog.com
これまでの伝統的なレイヤードアーキテクチャでは、純粋性で頑張ろうすると外部アクセスを必要とする場合にユースケースからの一連のテストをしないと品質保証がされないので大変だったが、できる限りリーフにしておけば純粋性を保ちつつテストも容易に作ることができる
「汎用」という言葉に二種類の意味がある
面白いと思ったは、「汎用」という言葉に二種類の意味があって違う品質特性に関わってくるという話し
「汎用」は「広範を扱える」という意味と「広範に使われる」という意味がある
- 「広範を扱える」は、例えば「運転免許証の提示」や「マイナンバーカードの提示」を「本人確認手段」のように定義しておけば、確認手段が増えても柔軟に対応できるし、会話する時の理解も簡単になるものをさす（柔軟性、理解容易性に関係する）
- 「広範に使われる」は、言語が備えるutilのような再利用性に関わってくるものをさす
なるべくこの両方の特性を持つように分割していくと
現場への適用
ゼロからアーキテクチャを考えるときはStratified Designでできる限り考えるのはいいかもしれないが、既存のプロジェクトでStratified Designを知らないチームの場合は、まずは レイヤードアーキテクチャのドメイン層だけでもStratified Design すると良さそう
