投稿元:
レビューを見る
クリーンアーキテクチャに限らず、アーキテクチャについての幅広い知見が詰まった一冊です。
もっと若いときに読んでおきたかった本です。
一方で、ある程度現実のソフトウェア開発を経験してからでないと理解しづらいかもしれません。
ところどころ読みづらい部分、やや冗長な部分があるので星マイナス1です。
投稿元:
レビューを見る
印象に残ったことメモ
- ソフトウェアアーキテクチャの目的は、「求められるシステムを構築、保守するために必要な人材を最小限に抑えること」である。
- 設計の品質は労力で計測できる。必要な労力が少なく、ライフタイム全体で低く保たれているならば、その設計は優れている。逆に、リリースごとに労力が増えるなら、その設計は優れていない。
- 崩壊したコードを書く方がクリーンなコードを書くより常に遅い。よくある、「あとでクリーンにすればいいよ。先に市場に出さなければ」これは、リリースごとの負担が増えていき、開発スピードが鈍化していき、先にクリーンにしているコードよりも後に市場に出る結果となることが経験的に多いそう。
- オブジェクト指向とは、「ポリモーフィズムを使用することで、システムにあるすべてのソースコードの依存関係を絶対的に制御する能力」そのために依存関係逆転の原則を使う。
- 言語パラダイムが進むにつれて進化しているのは、何をすべきではないか、である。
- 安定度/抽象度等価の原則「参照される数が多いモジュールほど抽象的に。参照される可能性がなければ無駄に抽象的にしない。」
- 選択肢を多く残す
上位方針(ビジネスルール、ビジネスロジック)から決める
詳細の決定はできるだけ遅延させる。選択肢を残す(データベース、フレームワーク、ウェブサーバー、GUI、IOなどは変化しやすい)
- ビジネスルール
これがエンティティオブジェクトとなる。エンティティは特定のフレームワークには依存せず、何にも依存しない Plain Old Data で作るべき
- ハードに依存しないコードを書く
レイヤ
- ソフトウェア :ハードウェアに依存しないコード
- ファームウェア :ハードウェアに依存するコード
- ハードウェア
- 組み込み開発では、できるだけファームウェアを書かない。ソフトウェアを書いて、できる限り寿命を延ばす。ハードウェアは進化していく。変化しやすいものに依存していると、そのコードも修正が必要。ハードウェアの変化に合わせてファームウェアは変化していくが、ソフトウェアは変化しない。
投稿元:
レビューを見る
半分も理解できた気がしないので評価は保留。
この本は基本的には業務アプリケーション向けで、小さなサービスならここまで考えるコスト賄えなさそう。
投稿元:
レビューを見る
コード片と文章で説明されているので、ある程度プログラマとしての経験がないと理解は難しいだろうなという印象。
デザインパターンが前提知識になっているんですが、あんな23個も覚える必要なかったな、、と遠い目で思います。
JJUGで聞いたクリーンアーキテクチャの実践は、やっぱり面倒だと思うし、規模にもよるけど、保守性を担保するのにここまでやる必要あるのかなと、やや懐疑的。
とりあえずコードは書けるようになったけど、きれいに書くにはどうしたら良いか迷ってる人にはオススメかも。
以下、気になったところの引用。
p34 ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。
p119 多くのアプリケーションにおいて、再利用性よりも保守性のほうが重要だ。
p244 ソフトウェアを構築する3つの活動
1.まずは動作させる。動作しなければ、仕事にならない。
2.それから、正しくする。あなたやほかの人たちが理解できるようにコードをリファクタリングして、ニーズの変化や理解の向上のためにコードを進化させていく。
3.それからら高速化する。「必要とされる」パフォーマンスのために、コードをリファクタリングする。
p259 アーキテクチャの観点では、データベースはエンティティではない。
投稿元:
レビューを見る
クリーンアーキテクチャについての本だが、ほとんどはその具体的な方法論ではなく良いアーキテクチャの定義に終始している。
そのため良いアーキテクトについて順を追って理解できる本であり、クリーンアーキテクチャ自体よりそこに到るまでの理論の方が重要だと感じた。
アーキテクトのトレンドはあれど、理論の部分に関しては何十年たっても変わることはないものなので、何周も読んで理解を深めていきたいと思う。
投稿元:
レビューを見る
優れたアーキテクトは境界を定義し、依存関係の方向性を自由に操り、決定を遅らせることができる。
アーキテクトは未来を常に予測し、境界を設けたときと設けなかったときのコストを意識しYAGNIと格闘し続ける道のりなんだろうなと感じた。
境界をひく正解がない以上、なぜその境界を引いたのか説明できるだけの根拠と経験をもってアーキテクチャを描こうと思った。
投稿元:
レビューを見る
設計の指針になることが書いてあります。この本を読んでから、インターフェイスを常に意識するようになりました。
投稿元:
レビューを見る
設計・アーキテクティングについて書かれた良書。他にアーキテクチャの本を余り読んでいないので比較対象が少ないが、何度も読んで身に着けよう、と思わせる本だった。
自分が理解できる事例に当てはめたり、実際にOOPしてみないと消化しきれないのだろうなぁ。
描かれている事例ではスッキリとはわからない感じ。それはまだ自分の経験が乏しいから?
行う責務を一つに絞ったコンポーネント化とか、それらコンポーネント間の依存関係の方向とかがメンテナンス性に大きく影響するのは本当にそうだろうな。
アーキテクチャにフレームワークやデータベースは登場しないとか。
MSAのデメリットについて語られているときの「サービス」の粒度が小さすぎて「それ、そもそも何もユーザに提供できていないからサービスじゃなくね?」みたいな疑問が渦巻いたり。
投稿元:
レビューを見る
みんな大好きボブおじさんの本。
おじさんの苦労話とそこから得られた様々なソフトウェアアーキテクチャに関する知見を教えてもらえる素敵なお話。
「ソフトウェアって変更できるからソフトウェアだよね」とか「XXXXは詳細」とかは名言だと思う。
ソフトウェア作ってる人はとりあえず読んでおいた方がいいんじゃないでしょうか。
投稿元:
レビューを見る
「アーキテクチャ」って何?という質問に説明できる人はどれだけいるでしょうか?
他に、「単一責任の原則」という、「一つのモジュール(ソース)は一つの責任者にすべき」という原則が書かれているのですが、この原則について、誰か教えてくれた人はいるでしょうか?
(実際、私は、この原則をわかっていたつもりですが、重要さを意識できておらず、業務上痛い経験があったため、この本の価値がわかりました)
要は、アーキテクチャを理解して、教えてくれる人は、なかなか周りにはいないと思います。
そのような貴重な情報を教えてくれるのがこの本だと思いました。(と言いつつ、私は、2回ぐらい読みましたが、まだまだ理解できていない部分も多く、また何年後かにチャレンジしたくなります)
翻訳ということもあり、文章は読みやすいとは言えないです。また、設計、プログラミング経験、実務経験をある程度持ってないと、イメージがしづらく、読んでいて腑に落ちないところはあるかと思います。
投稿元:
レビューを見る
第4部までと第5部以降で大きく感想が変わる本。
第4部まで(全体の半分弱)は以降の議論のための土台を用意するためにプログラミングパラダイムや SOLID 原則などが解説される。ここは概論がよくまとまっていて、読んでいて楽しい。
ただし、親切丁寧な解説というわけではないので紹介されるそれぞれの概念を初めて知る人向けというよりは、多少なりとも知っている人がよりクリアに理解するための文章という気がする。
第5部以降がこの本の主な主張かと思われるが、ここからは結構癖が強い。
有用な記述もあるものの、全体的な印象としては「理屈はわかるが、それは現実的か……?」と感じるものが多かった。
(あと、読んでいると何故かめちゃくちゃ眠くなる)
後半については原理主義的な強い主張が多く、実践に直結するかと問われると、個人的には No だと言わざるを得ない。
しかし、少しばかり極端な考え方に触れておくことは自分の思考の振り幅を広げる上で有用だと思うので、そういう意味では良い本だと思う。
投稿元:
レビューを見る
コードレベルのパラダイム、モジュールレベルとコンポーネントレベルの設計原則、アーキテクチャレベルの検討ポイントというように整理されて書かれているため、初学者でも混乱せずに学んでいくことができる。
投稿元:
レビューを見る
あの有名なアーキテクチャの図ばかりが取り上げられるがデータベースやWebといった「詳細」に依存しないようにビジネスロジックを再利用可能にし、ソフトウェアをソフトに保つアーキテクチャ設計が書かれた本。DDDと実装として使われることがあるけど、この本の中ではDDDという言葉は一度も使われてなくて意外だった。
投稿元:
レビューを見る
数年前にも読んだが、最近読み直した。
以前読んだ時よりは理解しながら読み進めることができた。
コードレベル・コンポーネントレベルで色々考えることがあるんだなと勉強になった。
投稿元:
レビューを見る
読む前はドーナツ型のいわゆるクリーンアーキテクチャの話なのかと思っていたが、実際にはプログラミングパラダイムやSOLID原則、凝集度結合度、テスタビリティのはなしも書かれていて勉強になった。
いわゆるクリーンアーキテクチャについては読むだけではぴんとこなかったので、簡単なPython CUIツールをクリーンアーキテクチャで作ってみた。(もちろん規模的に本来クリーンアーキテクチャを採用する必要はない)
https://github.com/takeoverjp/chisum
端的にいえば、ソースコードの依存は、変化の少ない上位レベルにのみむく。具体的には、同心円の境界では依存関係逆転の法則を使ってDIできるようにする。目的は、テスタビリティ向上、GUI先行開発、外部モジュール依存の低減低減など。たぶんDIしてる人からしたらそんな真新しいことは言ってない。四つのレベルに分けた同心円アーキテクチャが有名になりすぎてそれありきになってる気がするが、同心円の切り方は概要であり四つ以外にもあるだろう、と明言されている。また、境界は一度決めて終わりではなく、常に見張る必要がある。
たしかにテストはめちゃめちゃ書きやすい。ただ、クラス数がいたずらに増えるので、ボイラープレートコードが増えるのと、どこに書くべきか慣れるまで悩む。クリーンアーキテクチャ採用するならテスト書くのもセットでやらないと意味がない。
あと、34章にも記載があるが、アーキテクチャをビルドで強制するのが大事。Javaだとpackage local classを使ってある程度強制できるが、Pythonだと難しい。C++だとリンカーバージョンスクリプトで頑張るか、それはコストかかりすぎるから他のレイヤから呼び出せるかどうかでヘッダの場所を分けるとかを併せてやるべき。