#presentation Date : 2018/11/22 [https://youtu.be/5OjqD-ow8GE](https://youtu.be/5OjqD-ow8GE) - [[C4モデル]] で、レベル3 のコンポーネント図 から レベル4 のクラス図にしたタイミングで Component という概念が失われている。 - これは、 Java なども含めて多くの言語が Component や Layer などを第一級の言語機能として扱ってないためである。 - [[Just Enough Sowtware Architecture]] という本では、これを model-code gap と呼んでいる - コンポーネント図がコードに反映されずにギャップが存在する - > The code structure should reflect the architectural intent - Package by Layer -  - 責務によって分割する - 例えば、 Web, Service, Data で分けるみたいなイメージ - いわゆる Horizontal Slicing - Package by Feature -  - 機能によって分割する - いわゆる Vertical Slicing - Ports and adapter -  - inside (ドメイン) と outside (外部の技術詳細) に分ける - outside は inside に依存する 多くのアーキテクチャモデルは、[Curgo Culted Programming](https://en.wikipedia.org/wiki/Cargo_cult_programming) になってる - 「なぜ」ではなくただそれに従ってるだけの状態 > A big ball of mud is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expendiency than design. - 無計画に設計された構造は、設計ではなく利便性が優先される - 例えば、モジュールを飛び越えて呼び出しを行ったりとか、依存関係が不適切な呼び出しを行ったりとか - 現実的には、一貫性を制約やガイドラインによって保ちたい -  - こういう状況を避けたい - Static Analysis tool や Architecture Checking tool などもあるが、それはオフにもできてしまうし強制力が強いとまでは言えない - コンパイラの恩恵などを受けるために `Package by Component` はどうかという話 -  - ここでいう Component というのは [[C4 モデル]] での Component - マイクロサービスは、`Seprating Interface from Implementation` を実現できている -  - 他のサービスの Data Layer に直接アクセスすることができない - > The devil is in the implementation details - `public` キーワードが全て悪いのでは > if you make all types `public`, architectural styles can be conceptually different, but syntactically identical - package by feature や package by layer などを使ったとしてアーキテクチャの考え方が違うものの、構造的に同じである -  -  - > Use encapsulation to minimize the number of potential dependencies - > The surface area of yout internal public APIs should match your architectural intent > A good architecture rarely happens through architecture-indifferent design - トレードオフを考えずに選ぶだけでは、「良い」アーキテクチャにたどりつくことはほとんどない - > A good Atchitecture enables agility - これはタダで手に入るわけではなくある程度の up front thinking が必要になる