Clean Architecture 達人に学ぶソフトウェアの構造と設計

RobertC.Martin / 角征典 / 高木正弘

書いているコードが変わらないのだから、どんな種類のシステムでもソフトウェアアーキテクチャのルールは同じ。ソフトウェアアーキテクチャのルールとは、プログラムの構成要素をどのように組み立てるかのルールである。構成要素は普遍的で変わらないのだから、それらを組み立てるルールもまた、普遍的で変わらないのである。（本書「序文」より）

• カテゴリ: ビジネス・実用
• ジャンル: IT・コンピュータ / 全般
• 出版社: ドワンゴ
• 掲載誌・レーベル: アスキードワンゴ
• 電子版発売日: 2018年08月01日
• コンテンツ形式: EPUB
• サイズ(目安): 7MB

[ブクログ · ★★★★★]

現代のソフトウェア開発の基盤となる理論を紹介している本
ソフトウェア開発をするのであれば、確実に読んでおきたい一冊

[ブクログ · ★★★★★]

かなり納得できる内容で、読み終えてからもそのことばっかり考えてた。 「変化しやすいものに依存しない」って、人生でも組織でも大事だなと。 一方で、人生においては他人とのリレーション自体が最重要ビジネスロジックの一つなので、あんまり疎結合なのも良くないんだけど。 技術書でありながら、そこから哲学みたいなものも読み取ってしまったという、面白い経験だった。

[ブクログ · ★★★★★]

Clean AgileとClean Architectureを理解すればエンジアとしての思考の土台が固まる。

[ブクログ · ★★★★★]

みんな大好きボブおじさんの本。
おじさんの苦労話とそこから得られた様々なソフトウェアアーキテクチャに関する知見を教えてもらえる素敵なお話。
「ソフトウェアって変更できるからソフトウェアだよね」とか「XXXXは詳細」とかは名言だと思う。
ソフトウェア作ってる人はとりあえず読んでおいた方がいいんじゃないでしょうか。

[ブクログ · ★★★★★]

設計・アーキテクティングについて書かれた良書。他にアーキテクチャの本を余り読んでいないので比較対象が少ないが、何度も読んで身に着けよう、と思わせる本だった。

自分が理解できる事例に当てはめたり、実際にOOPしてみないと消化しきれないのだろうなぁ。
描かれている事例ではスッキリとはわからない感じ。それはまだ自分の経験が乏しいから？

行う責務を一つに絞ったコンポーネント化とか、それらコンポーネント間の依存関係の方向とかがメンテナンス性に大きく影響するのは本当にそうだろうな。

アーキテクチャにフレームワークやデータベースは登場しないとか。

MSAのデメリットについて語られているときの「サービス」の粒度が小さすぎて「それ、そもそも何もユーザに提供できていないからサービスじゃなくね？」みたいな疑問が渦巻いたり。

[ブクログ · ★★★★☆]

設計の原則、境界を定めること、フレームワークやデータベースは詳細とすることなど、多くの気付きがあった
すでに身に覚えがあるものも多い

アーキテクトだけでなくプログラマーこそ目を通しておくべきと思った

[ブクログ · ★★★★☆]

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Robert C. Martin氏の著書です。

Cleanシリーズの三冊目になります。

今回は、ソフトウェアアーキテクチャにフォーカスされた内容になっています。
ソフトウェアアーキテクチャとは、結局のところ設計と同じであること。
アーキテクチャは、「振る舞い」「構造」の2つの価値があり、後者により価値が高いこと。
それらを実現するための戦略と考え方が書かれています。

後半にでてくるクリーンアーキテクチャの図は有名ですね。

【本書で学べること・考えること】
- アーキテクチャとは
- プログラムのパラダイム
- 設計の原則（SOLID）
- コンポーネントの原則
- アーキテクチャの原則
- クリーンアーキテクチャ
- ボブおじさんの想い出

読んでみての感想です。

ソフトウェアアーキテクチャって、コードの上位概念のように考えていましたが、実際はコードそのものであると言ってもよいということが理解できました。
コードを原則に則って書き、コンポーネントを原則に則りまとめ、原則に則りシステムを構築する。
その過程で、決定をなるべく遅らせることで、より柔軟な「構造」をキープすることがアーキテクチャであるということです。
特に依存性の管理が重要であるということもわかりました。

実際の開発だとフレームワークが決まっていて、そのフレームワークのルールに合わせて実装することが多く、違いがあるなぁと思います、
本質的には、本書の方がよりソフトなのですが、そのためには高い技術力と知見を持ったメンバーも必要で、ハードルはかなり高いなと感じました。

ソフトウェアシステムだけでなく、ビジネス全体から詳細を見ることで、一段上のコードが書けるようになると思います。

[ブクログ · ★★★★☆]

数年前にも読んだが、最近読み直した。
以前読んだ時よりは理解しながら読み進めることができた。
コードレベル・コンポーネントレベルで色々考えることがあるんだなと勉強になった。

[ブクログ · ★★★★☆]

あの有名なアーキテクチャの図ばかりが取り上げられるがデータベースやWebといった「詳細」に依存しないようにビジネスロジックを再利用可能にし、ソフトウェアをソフトに保つアーキテクチャ設計が書かれた本。DDDと実装として使われることがあるけど、この本の中ではDDDという言葉は一度も使われてなくて意外だった。

[ブクログ · ★★★★☆]

「アーキテクチャ」って何？という質問に説明できる人はどれだけいるでしょうか？

他に、「単一責任の原則」という、「一つのモジュール（ソース）は一つの責任者にすべき」という原則が書かれているのですが、この原則について、誰か教えてくれた人はいるでしょうか？
（実際、私は、この原則をわかっていたつもりですが、重要さを意識できておらず、業務上痛い経験があったため、この本の価値がわかりました）

要は、アーキテクチャを理解して、教えてくれる人は、なかなか周りにはいないと思います。
そのような貴重な情報を教えてくれるのがこの本だと思いました。（と言いつつ、私は、2回ぐらい読みましたが、まだまだ理解できていない部分も多く、また何年後かにチャレンジしたくなります）

翻訳ということもあり、文章は読みやすいとは言えないです。また、設計、プログラミング経験、実務経験をある程度持ってないと、イメージがしづらく、読んでいて腑に落ちないところはあるかと思います。