ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ

  • オライリージャパン
3.83
  • (7)
  • (4)
  • (4)
  • (3)
  • (0)
本棚登録 : 271
感想 : 13
  • Amazon.co.jp ・本 (436ページ)
  • / ISBN・EAN: 9784873119823

作品紹介・あらすじ

モダンなソフトウェアアーキテクチャの基礎から全体像までを解説
分散システムやマイクロサービスなどなど現代的なソフトウェアアーキテクチャを考える際に必要となる知識、スキルやテクニックを解説する書籍です。アーキテクチャの原理から、異なるアーキテクチャの長所と短所の検証、アーキテクチャパターン、アーキテクチャの図示や表現方法などについて解説します。アーキテクチャを設計・実現していくために必要な知識やスキルを学ぶことができます。

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • 20代で読んでも理解できなかっただろうなー。アーキテクチャを大きな括りで整理しているのは素晴らしい。リスク分析の話とか良かった。ただ、アーキテクトは1人だけでCTO、みたいな小さな組織だと難しい話もあった。C4モデルとかArchiMateは、UMLで満足してる自分は、ちょっと触んないかなって思った。

  • 「ソフトウェアアーキテクチャの基礎」は良い本と思う。
    アーキテクトが読むべき本だったと思う。
    ラフなメモ。

    【1】ソフトウェアアーキテクチャの定義とは何か?
    以前の定義は、ソフトウェアアーキテクチャとは後から変更することが難しいモノだった。
    しかし、今は、マイクロサービスの出現により、変化しやすい設計を指すようになって、ガラリと変わった。

    【2】アーキテクチャの重要な要素は、トレードオフの決定だ。
    品質、コスト、スケジュール、スコープのバランスから、一番最良のものを選ぶ。
    それぞれの要素を最大限にするのではなく、トータルでバランスが取れているものを選ぶ。

    【3】アーキテクトに期待されている役割。

    アーキテクチャ決定を下す。
    アーキテクチャを継続的に分析する。
    アーキテクチャの最新のトレンドを把握している。
    アーキテクチャ決定の順序を徹底している。
    様々な技術に精通している。
    事業ドメインに詳しい。
    対人スキルや政治力を持つ。

    【4】ソフトウェアアーキテクチャを語る上で、XPの偉大さがある。

    XPでは、プロセスよりも経験的に知られていたプラクティスを重視した。
    たとえば、テストが多いほど品質が良くなる経験から、テスト駆動を生み出した。
    継続的インテグレーション、コードの共同所有、継続的デプロイなど。

    【5】ソフトウェアアーキテクチャの法則は2つ。

    1つは、トレードオフが全て。
    トレードオフが見つからないならば、分析が不十分な事実を知るべきだ。

    2つ目は、HowよりもWhyが大事。

    【6】モジュール性とは何なのか?

    モジュール分割するアーキテクチャのテクニックの利点は分かる。
    しかし、モジュールの実現方法はあまり知られていない、とメイヤーは言った。
    この話は、コンポーネント志向につながる。

    Javaならば、当初のJDKはパッケージで分割した。
    しかし、それだけでは扱いづらいので、Jarというコンポーネントが導入された。
    しかし、Jar同士でパッケージ名が衝突する場合があるから、module systemがJava9から導入された。
    つまり、Javaもモジュール性の実装方法に苦労している。

    【7】本の途中のコラムがとても参考になる。

    【7-1】スウェーデンで軍艦ヴァーサ号を製造したが、初めて処女航海に出ようとした時に、すぐに港で沈没した話。

    失敗の原因は、アーキテクチャ特性を全部盛り込みすぎて、軍艦が重すぎてしまい、バランスが取れなくなり沈没した。
    数多くの利害関係者の要求を最新鋭の軍艦に盛り込んだために、軍艦として実現できなかった。

    今のソフトウェアアーキテクチャの話も同じ。
    ユーザのたくさんの要望を盛り込みすぎると、結局使い勝手の悪いシステムになってしまうし、それ以前にスケジュールが伸びすぎて永遠にリリースされないシステムになるリスクすらある。

    【7-2】ドメイン駆動設計の意義は、境界づけられたコンテキストという概念により、アーキテクチャ設計手法が大きく変わった点にある。

    ドメイン駆動設計の出現以前は、組織内の共通エンティティは再利用を重視していた。
    しかし、再利用を重視しすぎて、ビルドが困難になり、チーム感の調整が難しくなり、ソフトウェアの複雑さが増大し、多くの問題を引き起こした。
    たぶん、ソフトウェアプロダクトラインの話も同じ。

    ドメイン駆動設計の出現後、境界づけられたコンテキストの考え方により、各エンティティは局所化されたコンテキストの中で最もよく機能すればいい。
    つまり、組織全体の共通エンティティは不要であって、問題領域ごとにエンティティを自由に作り、その中で最適化されたエンティティを作ればいい。
    問題領域のドメインの境界上で調整すればいい。
    つまり、この考え方がマイクロサービスにつながるわけだ。
    マイクロサービスの実装言語はGo言語が主流である。

    各ドメイン内のシステムはRailsだったりPythonだったりPHPでもよく、複数のプログラミング言語で作られたシステムとGo言語によるマイクロサービスがAWSのようなクラウド上で動くアーキテクチャが多いわけだ。

    【8】コンポーネント設計では、分割の観点は何か?

    コンポーネント設計とは、アーキテクチャの分割であるという考え方。
    レイヤーアーキテクチャがよく使われる。
    たとえば、Javaの依存性注入(DI)、DLLやJarなどのコンポーネント。

    この考え方を進めると、開発スタイルはコンウェイの法則に縛られることになり、複雑な組織構造が反映された複雑なアーキテクチャになってしまう。
    だから、逆コンウェイ戦略という考え方が出てきた。

    一方、コンポーネント設計とは、ドメインによる分割であるという考え方。
    これはドメイン駆動設計であり、マイクロサービスアーキテクチャにつながる。

    ドメインごとに開発チームを作ることにより、コンウェイの法則のリスクを避けられる。
    逆コンウェイ戦略をそのまま実現しやすい。

    【9】アーキテクチャスタイルとは、アーキテクチャのパターン集。

    モノリシックアーキテクチャと分散アーキテクチャに分かれる。

    モノリシックアーキテクチャ:

    レイヤーアーキテクチャ →TCP/IPとか。
    パイプラインアーキテクチャ →Unixとか。
    マイクロカーネルアーキテクチャ →コアシステム+プラグインの構造。Eclipse、Jira、Jenkinsとか。

    分散アーキテクチャ:

    サービスベースアーキテクチャ →フロントエンド+バックエンド
    イベント駆動アーキテクチャ →デスクトップアプリ。非同期システム。
    スペースベースアーキテクチャ →ロードバランサー。インフラの仮想化。クラウド。
    オーケストレーション駆動サービス指向アーキテクチャ →よく分からない。使われない。
    マイクロサービスアーキテクチャ →ドメイン駆動設計とか。

    分散アーキテクチャが今の流行だが、8個の誤信がある。
    ネットワークは信頼できる。
    レイテンシーがゼロ。
    帯域幅は無限。
    ネットワークは安全。
    トポロジーは決して変化しない。
    管理者は1人だけ。
    転送コストはゼロ。
    ネットワークは均一。

    他にも、分散ロギング、分散トランザクションなどもある。

    これらの観点をトレードオフとして考えるべき。

  • ソフトウェアアーキテクチャの基礎 エンジニアリングに基づく体系的アプローチ

    ソフトウェアアーキテクトのMark Richards氏とNeal Ford氏の著書です。

    【本書で学べること・考えること】
    - ソフトウェアアーキテクチャとは
    - アーキテクトの役割
    - アーキテクチャ特性
    - アーキテクチャスタイル
    - アーキテクチャスタイルと特性(代表例)
    - アーキテクトに求められるソフトスキル

    読んでみての感想です。

    「トレードオフ」「場合による」がこの本のキーワードです。

    この本は、ソフトウェア開発に携わる人にはレベルを問わず読んで欲しいです。
    本書で得た知識があれば、今まで以上に俯瞰的な視点で自分の担当業務が見れるようになります。
    特になぜこのような構成になっているかを意識するかしないかで、大きな差が生まれてきます。

    また、代表的なアーキテクチャスタイルの説明とアーキテクチャ特性が載っているので、体系的に理解しやすいです。
    以下の4つが現状では大事だということも理解できます。
    ・レーヤードアーキテクチャ
    ・スペースベースアーキテクチャ
    ・イベント駆動アーキテクチャ
    ・マイクロサービスアーキテクチャ

    ソフトスキルについては、本書でなくても他に良書がありますので、そちらを参照するのも良いかと思います。
    私は、上司から優しく接せられると・・・何かあるな!?と勘ぐってしまします。

  • いろんなアーキテクチャとその特性の比較を知りたいと思って手に取ったが本書はまさに自分の知りたいことが書いてあった。各アーキテクチャの説明に1/3を費やしている。そして、それ以外の章を読み進めていくと、なぜそんなに章を費やすのかがわかる。それは冒頭にある通り、ソフトウェアアーキテクチャはトレードオフであるからだ。本書はまさにトレードオフをするための基礎を培うために存在するといえる。

  • ジュニアレベルの自分的には、コナーセンスの概念はめちゃめちゃためになった。アーキテクチャの本編ではないが…。コードレビューする時に「こっちは意味のコナーセンスになんでこっちの書き方の方がいいですよね〜」みたいな共通認識が作れそう。

  • アーキテクチャの歴史的変遷とかモダンなアーキテクチャの位置付けとか勉強なった。

  • > アーキテクチャには正解も間違いもない。ただトレードオフがあるだけだ。

  • 請求記号 007.61/R 35

  • 話題だったのと、アーキテクチャを主題として体系的な情報にするとどうなるのか関心があったので読んでみました。アーキテクトとして知るべき全体像や振る舞いについて書かれていました。アーキテクチャを相対的に評価する提案と、実際にいくつかのアーキテクチャについていわゆる「イリティ」の観点で評価を試みています。その中身をアーキテクチャについて工学あるいはコンピュータサイエンスの領域として説明されたいと思いましたが、その期待にはそえませんでした。

  • はじめに、マイクロサービスアーキテクチャなど、各アーキテクチャについて解説されている本、ではありません。そういった解説もありますが、それが主ではありません。

    アーキテクチャの特徴についての解説や、アーキテクチャ選択や設計に必要な考え方だけでなく、

    - そもそもアーキテクトに期待される職能とは
    - アーキテクトとしてものごとの見方
    - アーキテクトとしての立ち振る舞い
    - 開発チームやステークホルダーと渡り合うためのソーシャルスキル
    - どう技術と付き合っていくか、キャリアパスをどうするか、ソフトスキル

    など、アーキテクチャについての解説書というより、アーキテクトとしてのHOWTOといった感じで、エンジニアとしてアーキテクチャ理解を深めたい人向けではありません。

    僕の場合はアーキテクトとして、チームをリードする必要性を感じているところだったので、とても重要な内容が書かれていると感じました。ただ、一度読んでなるほど!という内容でもなく、経験を思い返しながら、繰り返し読み込んでいく必要があると感じました。

全13件中 1 - 10件を表示

Mark Richardsの作品

  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×