 |
Clean Architecture 達人に学ぶソフトウェアの構造と設計 新品価格 |
Clean Architecture 達人に学ぶソフトウェアの構造と設計
を読んだ
マスタカと言えばクリーンな人間
そう潔癖症である！
そんなわけで本書を読んだわけだ
以下、面白かった内容をつらつら買いていく
・まとめ
詳細に依存するな
インタフェースを切って詳細を隠蔽しよう
これで詳細が何に変わっても問題がない
・システムの価値
変更できないシステムに価値はない
・重要と緊急
1.緊急かつ重要
2.緊急でないが重要
3.緊急だが重要でない
4.緊急でも重要でもない
1と2がアーキテクチャ
1と3が振る舞い
マネージャーは3を1に昇格させようとする
なので開発者は2が重要なことを主張する必要がある
・依存関係の逆転
インタフェースに依存させる実装をし
抽象に依存するようにしよう
・SOLID原則
SRP単一責任の原則：
個々のモジュールの変更理由がたった一つになるようにする
一つのアクターには一つの関数
OCPオープンクローズドの原則：
既存のコードの変更よりも新しいコードの追加によってシステムの振る舞いを変更できるようにする
LSPリスコフの置換原則：
個々のパーツが交換可能になるようにする
ISPインタフェース分離の原則：
使ってないものへの依存を回避すべき
DIP依存関係逆転の原則：
上位レベルの方針の実装コードは、下位レベルの詳細の実装コードに依存するべきでない
・アーキテクチャの主な目的
システムのライフサイクルをサポートすること
優れたアーキテクチャであれば、容易に理解・開発・保守・デプロイできる
最終目的は、システムのライフサイクルコストを最小限に抑え
プログラマの生産性を最大にすることである
・選択肢を残しておく
アーキテクトは方針をきめるだけで詳細の決定を遅らす
例えばDBは最初に決めない。
こうすることで決定するまでに得る情報が多くなる
・システムの切り離し方式
ソースコードレベルで分離
一つの変更が他のモジュールの再コンパイルに繋がらないようにする
Gem等で分離すること
デプロイレベルで分離
あるモジュールに対する変更が他のモジュールのデプロイに影響しないようにする
jar等
サービスレベル
ネットワークパケットで通信する。マイクロサービスなど
・アーキテクトは切り離しをどう扱うか
先ほど同様に選択肢は最後まで残す
サービスレベルで分離できそうな形で作るが、開発初期ではモノリシックで良いのでは
・選択肢を残すために
境界を引いて最後まで選択を保留する
最初はDBじゃなくて、ファイルシステムだけで良いかも
DBはビジネスルールを知っているが、ビジネスルールはDBを知る必要がない
・ハードウェア
ハードウェアは詳細
将来変わる可能性があるよ
・レイヤードアーキテクチャ
厳格なレイヤードアーキテクチャは次の下位レベルしか依存できない
飛び越えて下に行く場合は緩いレイヤードアーキテクチャになる
・アーキテクチャ4種類
水平方向のレイヤード
機能によるパッケージング
ControllerからDBアクセスまで同じ機能なら一つとして扱う
垂直方向のレイヤーリング
ポートとアダプター
外と内で分ける
view(外)とロジック(内)とDB(外)にわける
コンポーネント
デプロイ単位でわける
コントローラーとその他で分けるイメージ
ソフトウェア開発してる人なら綺麗なアーキテクチャにしたいと思います
その手助けになる1冊です
ソフトウェア開発に関わる人はぜひどうぞ
