Partial Boundary
参考
図解
>
>WIP
---------------
例
最後のステップを省略する
片方だけの境界
Facadeパターン
序盤にBoundaryを作ることはオーバーエンジニアリングとみなされることもあるが、後からBoundaryを作ることのコストは実際大きい
将来を見越しながら、どのレベルのBoundaryを用意すべきかを常に検討する必要がある
最後のステップを省略する
同一のComponentの中に存在はするが、内部では厳格に境界が区切られている
言うなれば、今すぐにでも物理的にシステムを独立させても耐えるぞ、という状態
「最後のステップの省略」とは、「あとはCompoentを分けるだけ」ということ
Componentには分かれていないので、「部分的な境界」であると言える
マイクロサービス的な辛みを受けないことがメリット
modular monorithがまさにそれだろう
3つの中では最もコストが高い
片方だけの境界
>
Client → Interface ← Implのように、片側だけInterfaceを用意する
DIPは達成できている
問題は上記の点線のような境界の違反を防ぐすべがないこと
>
Facade classが境界としてギリ存在している
Interfaceの仲介などを特にしていない
各Serviceの実装が変更されると、Clientも再compileが必要になる
3つの中では最も緩い
実際はもっと色々な境界の作り方とそのレベルが存在するだろう
深掘りする価値がありそう
境界の作り方にはレベルがあることを認識する
それぞれの作成・メンテコストを考える
どういう判断でそのレベルを選択するのかを考える
将来に備える v.s. 将来に備えすぎない、のトレードオフ
>
moduleの構成の分類
もっとありそう