Please enable JavaScript.

Coggle requires JavaScript to display documents.

Clean Architecture (アーキテクチャ (独立性 (切り離し方式 (ソースコードレベル (ソースコードモジュール間の依存性を管理する…

- - - - 開発
        
        開発初期・小さなチームでは，強固なアーキテクチャは開発の障害になると考えられ，コンポーネントやインターフェースが明確に定義できていないモノリシックなシステムでの開発が進みがち
        
        複数チームでの開発では，信頼性の高い，安定したインターフェースで明確にコンポーネントを分割する必要がある
      - デプロイ
        
        デプロイのコストが高ければ，その分だけシステムの有用性は低下する
        
        デプロイ戦略を考え，単一のアクションで簡単にデプロイできるようにするべき
        
        例：マイクロサービスアーキテクチャ導入 -> 多数のサービスを導入したサイン，デプロイ時の各サービス設定・接続・起動タイミングの調整をどうするのかを予め考える必要がある
      - 運用
        
        優れたアーキテクチャはシステム運用方法の理解を助ける
      - 保守
        
        主なコストは洞窟探検とリスク
        
        洞窟探検：新しい機能の追加や血管の修正において，既存のソフトウェアを掘り起こし，最適な場所や戦略を見つけるコスト
        
        リスク：変更を行ううちに，意図しないバグを生み出す可能性
        
        アーキテクチャを慎重に考え, システムを安定したインターフェースを持つ独立したコンポーネントにしておけば，これらのコストを大幅に減らすことができる
      - 選択肢をなるべく長く残す
        
        アーキテクトは方針とは無関係に詳細を決めるようにすることで，詳細決定を先延ばしにするべき
        
        方針：ビジネスの全てのルールや手順を含む
        
        詳細：DB・フレームワークなど，方針についてやり取りするために必要なもの
        
        先に上位の方針のみ決定していくことで，詳細決定のために必要な情報を数多く手に入れる時間を確保できる
        
        優れたアーキテクトは
        
        方針と詳細を慎重に区別して，方針が詳細を把握せず，依存することがないように両者を切り離す
        
        詳細の決定をできるだけ延期・保留できるように方針をデザインする
  - - - システムの意図を考慮して，異なる理由で変更されるものを分離する．例えばシステムを以下のレイヤーに分割する
        
        ユーザーインターフェース
        
        アプリケーション特有のビジネスルール
        
        入力フィールドの検証etc
        
        アプリケーションに依存しないビジネスルール
        
        口座のり率計算など，ドメインに密接に結びつくルールetc
        
        データベース
    - - ユースケース毎に水平分割したシステムを構築する
        
        注文入力・追加と注文削除は異なる頻度と理由で変更されると考えられるので，それぞれに対して水平分割したシステムを構築
        
        古いユースケースと新しいユースケースを独立させることで，変更しやすくなる
        流れとしては一つの大きな水平分割されたシステムが合って，更にそれらをユースケースで分割していく？最初からよく考えられていれば逆もありうるか,
    - - システムの重複を削除するために安易に統合してはいけない
        
        ユースケースを分割している場合
        
        画面構成が同じ２つのユースケースがある, コードを共有するべきか？？
        
        現在たまたま被っているだけで，最終的には別物になる可能性が高くないか考える必要がある
        
        レイヤーを水平分割している場合　
        
        DBのレコードのデータ構造と，ある画面のデータ構造がよく似ている
        
        ビューモデルを作成して要素をコピーするのではなく，DBのレコードをそのままUIに渡したくなる
        
        これは偶然の重複であり，今後画面が変わる可能性が高い
    - - ソースコードレベル
        
        ソースコードモジュール間の依存性を管理する (Ruby Gemsなど)
        
        コンポーネントは全て同じアドレス空間で実行される
        
        コンポーネント間の通信：単純な関数呼び出し
        
        単一の実行ファイルがメモリに読み込まれる
      - デプロイレベル
        
        単独デプロイ可能な単位で依存関係を管理する
        
        (jar, DLL, 共有ライブラリetc)
        
        あるモジュールのソースコード変更が，他のモジュールの再ビルドや再デプロイにつながらないようにする
        
        多くのコンポーネントは同じメモリアドレス空間に存在し，関数呼び出しで通信
        
        同じプロセッサの別プロセスに存在，プロセス間通信・ソケット・共有メモリなどを使用するコンポーネントもある
      - サービスレベル
        
        データ構造のレベルまで依存性を管理する
        
        コンポーネントはネットワークパケットだけで通信
        
        全ての実行単位を完全に独立させるのでソースやバイナリを変更しても互いに影響を与えることはない
        
        サービス，マイクロサービスetc
        
        つまり分割して api でのやり取りにすると
        
        戻り値, URI 等を変えなければクラス名や内部実装が変わっても問題ない
      - どの方式を取るべきか？
        
        単一サーバで快適に動かせるうちは，ソースコードの切り離しで十分
        
        負荷が増えてきたらデプロイ可能な単位やサービスで切り出し，複数のサーバで動かす
        
        不要なサービス境界への対応に労力を割くことにならないように注意
  - - - 独立してコンパイルやデプロイが可能なコンポーネントを準備した後で，それらを同じコンポーネントにまとめる
        
        複数のバージョン番号やリリース管理の負担がなくなる
        そもそもMaven, Gradle 等で管理は簡略化されているのでこの方針は特に効果はない？
      - 片方だけの境界 (Strategy パターン)
        
        アーキテクチャの完全な境界は双方向の分離を維持知るために両側にインターフェースを使用しているがその実装・保守はコストが高い
        
        後から完全な境界にする余地を残して，片方だけ実装する
        
        例
        
        Client は ServceBourdary(Interface) を介して Service Impl を呼び出す
        
        ServiceImpl から Client の直接呼び出しも可能(インターフェースを介さない）
        
        ー＞ Client 側にはインターフェースが無いため，Service が Client に依存するような実装をしてしまうと，Client が変更された際に Serviceも影響を受ける
        
        本来，原則に従って Client -> Service という一方向の依存であるべきだが，Service -> Client という依存を作ってしまった場合に問題となる
        
        双方向にインターフェースを実装しておけばこうした問題も避けられるが
        
        この問題は発生しうるのか？？原則に従わない実装が必要となるケースはなんだろうか？
      - Facade
        
        インターフェースは作成せず，境界はFacadeパターンで作成する
        
        全てのサービスはこのクラスのメソッドになり，クライアントはこのクラス経由でサービスを呼び出す
        
        静的言語では Service クラスのいずれかのソースコードを変更すると Client も再コンパイルが必要になる
        
        片方だけの境界同様，Service -> Cline の依存を作ってしまうと問題になる
- - - - ファサードパターン
        
        データと処理を分離
        
        処理はアクター毎に分離してクラス化
        
        ファサードクラスはそれぞれの処理クラスのインスタンスからそれぞれの処理を呼び出すだけ
      - コンポーネントレベル：閉鎖性共通の原則
        アーキテクチャレベル：変更の軸
  - - - 変化しやすい具象クラスを参照しない
        AbstractFactory パターンを使う
      - 変化しやすい具象クラスを継承しない
        
        ??インターフェースの実装のみということ？
      - 具象関数をオーバーライドしない
        
        元の関数を抽象関数にして，共通インターフェースの複数の実装を用意する
        
        オーバーライドしても依存関係を排除できず，そのまま継承することになるため？？
- - - - 再利用の単位とリリースの単位は等価になる
        
        一つのコンポーネントを形成するクラスやモジュールは，まとめてリリース可能でなければならない
        
        同じバージョン番号，同じリリースプロセス，同じリリースドキュメントを有していたほうがわかりやすい
    - - 同じ理由，同じタイミングで変更されるクラスをコンポーネントにまとめる
        
        変更の理由やタイミングが異なるクラスは別のコンポーネントに分ける
      - 単一責任の原則
        - クラスを変更する理由が複数あるべきではない
        閉鎖性共通の原則
        
        コンポーネントを変更する理由が複数あるべきではない
        
        変更箇所がまとまっていた方が，
        変更しやすくデプロイの手間も少ない
    - - コンポーネントのユーザーに対して実際には使わないものへの依存を強要してはいけない
        
        コンポーネントに依存するのであれば，コンポーネントに含まれる全てのクラスに依存するようにしておきたい -> 本来不要な際デプロイを避けられる
        
        依存するクラスもあれば，依存しないクラスもあるような状況を避ける -> 過度な凝集を防ぐ
  - - - コンポーネントの依存グラフに循環依存があってはいけない
        
        循環があると，ユニットテストやリリースが難しくなる
        
        コンポーネントのビルド順番を決めるのも難しくなる
      - javaのようにコンパイル済みのバイナリで他のコンポーネントを参照するような言語では厄介な問題に繋がる可能性がある
      - 循環依存の解消
        
        A -> B とコンポーネントが依存している場合
        
        B 内の必要とするメソッドを持つインターフェースを A 内に作ってしまう (B 内の実装は A内のインターフェース依存にする）
        
        インターフェース的には B -> A の依存関係になる（依存関係逆転の原則)
        
        さらに，A, B が両方が依存するコンポーネント C を作成し，インターフェース，具象を写せば A -> C, B -> C となり依存関係は完全になくなる
    - - 安定度の高い方向に依存する
        
        変動を想定したコンポーネントは，変更しづらいコンポーネントから依存されてはいけない
        
        それ自体は変更しやすい設計になっていても，依存されると途端に変更しづらくなる
      - 安定度の指標
        
        自分に依存しているコンポーネントが多いほど変更しづらい -> 変更が加えられにくく，安定度は高くなる
        
        逆に依存するコンポーネントが多いほど，それらの変更に伴い変更しなくてはいけなくなるので安定度は低くなる
      - 依存関係を辿っていくと，安定度が単調増加してくような構成が望ましい
        
        安定度が高いコンポーネントが低いものに依存している場合は，依存関係逆転の法則でインターフェース，更には具象の切り出しを行なう (切り出したコンポーネントの安定性は高くする（なる））
    - - 安定度の高いコンポーネントは抽象度も高くあるべきで，安定度の高さが拡張の妨げになってしまってはいけない
        
        上位レベルのビジネスやアーキテクチャに関する決定は頻繁に変わって欲しくない
        
        上位レベルの方針を安定度の高いコンポーネントに配置すると，方針を表現しているソースコードを変更しづらくなる
        
        抽象クラスを作成することで，既存コードを変更せず拡張できるようにしておく
        　- 方針=インターフェース？だけ抽象クラスで表現
        　- 「方針の表現」つまり具象(実装）は別コンポーネントに
      - 安定度の低いコンポーネントは具体的なものであるべき, 低いことによって，内部の具体的なコードが変更しやすくなる
      - 安定依存の原則と合わせて考えると
        抽象度が高（安定度が高）くなる方向に依存すべき
    - - 苦痛ゾーン (安定度最高 x 抽象度最低)
        
        きちんと設計したコンポーネントがここに来ることは無い
        
        構成要素の特性的にここに来るもの
        
        データベーススキーマ
        - 変更されやすく，極めて抽象度が高く，他のコンポーネントから依存されまくっている - オブジェクト指向アプリケーションとDBとのインターフェースをきちんと管理するのは難しく，スキーマの変更は苦痛を伴う
        
        具象ユーティリティライブラリ ( String etc)
        - 実際にはほとんど変更されることはないので問題にならない **変動性が低い**
        
        DBスキーマは変更されやすいか？？変更するとなったら苦痛は大きそう
      - 無駄ゾーン(安定度最低 x 抽象度最高)
        
        依存するコンポーネントが存在しない抽象コンポーネント
      - 主系列（望ましいゾーン）
        ：下記２領域を結ぶ直線領域(本の図を参照のこと)
        
        安定度最高，抽象度最高
        
        安定度最低，抽象度最低
        
        設計・実装方針
        
        主系列の両端どちらかにコンポーネントが収まっているのが望ましい
        
        そうできない場合は主系列上に乗せて安定度と抽象度のバランスを保つ
        
        もしくは，主系列からの距離を最小にできるようにする