達人に学ぶソフトウェアの構造と設計を読んだので、まとめてみます。コメントやツッコミなどのフィードバックがあればうれしいです。続編としてクリーンアーキテクチャ本を読むためのポイントという記事を書きました。良著?著者のロバート・C・マーチン(著書読んだことあるかも?)は、50年前から現代に至るまで、様々なアーキテクチャを見て、第一線級として開発し続けてきた経験を元に、どのアーキテクチャでもクリーンにしようとするなら、基本部分は変わらないと言ってて、それらが美味くまとまった本だからです。Architectureそのものについてはほとんど割かれていません。それくらい、基本として知るべき事が書かれた本なのです。最近のアーキテクチャを追いかけている人たちにとっては、どれも割と当たり前の内容でしょう。いう人は元ネタや、その後の議論を追いかけるだけで事足りるはずです。本や、この記事に出てくる知識という言葉は、名前や構造など全てを指します。あるモジュールのファイル名や、中のクラス名、メソッドの有無、データの型、中の実装などは全て知識です。Architectureという2012年のブログです。Architecture翻訳)という2015年に翻訳された記事もあるので、読んでみるといいかもしれません。Architectureは、DDDでもおなじみのレイヤーアーキテクチャの考えと、ヘキサゴナルアーキテクチャ(ポートとアダプタデザインパターン)や、他のいくつかのレイヤーアーキテクチャなどの成果を踏まえた、よりシンプルで強力なアーキテクチャを提唱するものです。Architectureを構成する要件しか書いていません。Architectureを理解するために必要な要素や背景をまとめたもので、アーキテクチャ論としての、クリーンなアーキテクチャについて理解する為の内容(いわば基本)が大半を占めています。プログラミングパラダイムの話3つのプログラミングパラダイム(構造化プログラミング、オブジェクト指向プログラミング、関数型プログラミング)は50年以上前からあったが、それらは本質的には3つの制約を課すものだと述べています。最後のは、異論が残りそうなヤツですがそれはさておいて、どのプログラミングパラダイムもいい感じの案配で使い分けると良いと思います。現代のプログラミング言語や流行は大体そういう方向性です。SOLID原則オブジェクト指向プログラミングでよく出てくるやつです。依存性逆流の原則(ビジネスロジックなどの上位概念は、より下位にある詳細の知識に依存せず書く原則と、それを実現するためのデザインパターン)どれも大体は言ってることは似ていて「ある集団はシンプルに保つ」「不必要な知識を露出しない」というものです。ここでいう詳細とは、RDBやAPIアクセス、ウェブ、フレームワークなどを指しています。ビジネスロジックやドメイン知識といった抽象化された概念とは異なり、実世界との関わりを強く持ったものが詳細です。これらを守ると疎結合やテスタブル(ユニットテストしやすい)になり、メンテしやすくなるというメリットがあります。Principleは、安定してるものに依存しようという原則です。ある集団はそれが依存している先が少ないほど安定しているし、依存されてるほど安定しています。前者は、依存先が多いとそれだけ依存先の変更に左右されてしまいます。後者は、変更をすると影響が大きいので安定せざるを得ないという理由です。ここでいう依存とは、知識を利用すること全てになります。安定度は大体抽象度と同じになる(厳密に気にしても仕方ないけど、指針にはなるかも)最近話題のスパゲティコードの件は、大体が安定に関する原則を守れていないことと、その前提となる適切な集団作りに失敗していることに起因します。アーキテクチャアーキテクチャとは目的に沿ったシステムを作るために、システムの線引き(境界)と境界面をどう扱えば、変更に強いものになるか?です。詳細(フレームワークとかRDBとかウェブとかその他)にあたるものの決定を出来うるかぎり先延ばしにする。その為にバウンダリなどを用いた抽象化を活用する。しておけば最悪乗り換える時でも変更は最小限に抑えられる。境界の設定と境界面の取り扱い方をマスターしようぜという話です。Architectureです。それぞれのレイヤーは基本的には、とてもテスタブルになるエンティティ層とユースケース層を分けなくてもいいケースは、普通にありそうだし、最も外側の層は要らない可能性も普通にありそうです。エンタープライズなシステムを作るなら、4層+αになるでしょうが、2層だけでも十分価値がありますし、練習するならそこから始めるといいでしょう。そもそも、クリーンアーキテクチャで有名なよく見かける図は、ただのコンセプト図なので、実際のシステムにおいては様々な構成があり得ます。思考停止せずに、それでいてクリーンにする原則(ここまでに出てきた全ての話)を破らないように、システムをアーキテクトしましょう。層なんかも、横に依存するのは避けるべきです(これまでのクリーンなアーキテクチャの原則で考えると、横には超えるべきではない境界があるでしょう)Hambleオブジェクトパターンテスタブルなものと、そうじゃないものを分離しとくと便利というデザインパターンです。本の例ではViewとPresenterという分け方をしていてViewはテストしづらいHambleオブジェクトであり、Presenterは、Viewからテスタブルな部分を抽出したものとしています。まとめプログラミングパラダイムに感謝を捧げながら設計の基本を守ればクリーンになるし、レイヤーを疎結合にして、依存を一方通行にすればテスタブルにもなるし、変更にも強くしやすいという理解をしています。FacebookのFLUXも、循環はするものの依存性を一方通行にすることで、これまでの双方向性がもたらす組み合わせ爆発的な無秩序を防ぐアイデアで、有用性が大きく実証されています。ウェブ開発でも随所で役立つものでしょう。必要なことは、適切なグルーピングと抽象化をして、早すぎる詳細決定を排除することです。(早すぎる抽象化も、早すぎる最適化もどっちもダメ!という話ですね)今後、もっとかみ砕いた上で詳細な記事を書いたり、TypeScriptで実現するクリーンアーキテクチャの記事(と技術同人誌)を書く予定です。間違いなどあればご指摘いただけると幸いです。他感想、コメントなどいただければ幸いです。続編としてクリーンアーキテクチャ本を読むためのポイントという記事を書きました。ダウンロード#プログラミング#コンピュータサイエンス#アーキテクチャ#クリーンアーキテクチャこの記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。系記事まとめnoteに投稿されたエンジニア系の記事のまとめ。コーディングTIPSよりは、考察や意見などを中心に。Osumi久々に興奮する本に出会った。クリエイターへのお問合せnoteカイゼン目安箱クリエイターの。