「Design It!」は、人生に影響を与える本になりそうです

設計から携われるタスクがあり希望の上、チーム異動しました。どのように設計を行うか、何を考慮する必要があるのか、どのように関係者(ステークホルダー)に説明するかなど、ありとあらゆることが手探り状態です。「Design It!」を読んだことで具体的なアクションまで落とし込めたような気がします。あとは、歯を食いしばってやるだけです。

Design It! ―プログラマーのためのアーキテクティング入門

概要

本書は、3部構成でした。目次は以下の通りです。

アーキテクトの道具箱は、実践で困った時に辞書的に使う時に読むものだと思います。演習問題で本当に使える知識なっているかを確認することができます。一人でやっても効果が薄いと思ったので、時間があるときに勉強会を開いてワイワイしながら解きたいと思える内容でした。

• 第I部 ソフトウェアアーキテクチャ入門

  • 1章 ソフトウェアアーキテクトになる
  • 2章 デザイン思考の基礎

• 第II部 アーキテクチャ設計の基礎

  • 3章 デザイン戦略を立てる
  • 4章 ステークホルダーに共感する
  • 5章 アーキテクチャ上重要な要求を掘り下げる
  • 6章 アーキテクチャを選ぶ(君がアーキテクチャに選ばれる前に)
  • 7章 パターンで土台を作る
  • 8章 意味のあるモデルで複雑さを扱う
  • 9章 アーキテクチャデザインスタジオを開く
  • 10章 設計判断を可視化する
  • 11章 アーキテクチャを記述する
  • 12章 アーキテクチャに通知表をつける
  • 13章 チームのアーキテクト力を強める

• 第III部 アーキテクトの道具箱

  • 14章 問題理解のアクティビティ
  • 15章 潜在的な解決策を探るアクティビティ
  • 16章 設計をタンジブルにするアクティビティ
  • 17章 設計の選択肢を評価するアクティビティ

以下、書籍を読みながら取ったメモを残しておこうと思います。

アーキテクチャ上重要な要求を掘り下げる

• アーキテクチャ上重要な要求(ASR)
  • 制約
    • 一旦決定してしまうと交渉不可能となるので、主導権を握っておきたい
  • 品質特性
    • 外部から観測可能
  • 影響を与える機能要求
  • その他の影響を及ぼすもの

制約には、「与えられた制約」とシステムが成長するに伴って増える技術的負債のような「与えられた制約」がある。

ASRを見つけるために、ステークホルダーが何に気をかけているのかを問いづづける。 2人の人物が品質特性シナリオ読んだ時、システムについて同じ理解をしなければならない。

アーキテクチャを選ぶ(君がアーキテクチャに選ばれる前に)

ソフトウェアアーキテクチャを設計するということは、不確実性のもとで決定を下すということ。

ソフトウェアアーキテクチャを選択する際には、ステークホルダーが判断しやすいようにトレードオフ分析できる意思決定マトリクスを作成する。

パターンで土台を作る

• レイヤー
  • 機能的にまとまったモジュールのグループ
  • 上位層は下位層の利用が許可されているが、その逆は成り立たない
• ポートとアダプタ
  • 核となるビジネスロジックを分離する
• パイプとフィルタ
  • フィルタと呼ばれるコンポーネント群が一つの変換またはデータ操作を担当する
• サービス指向アーキテクチャ
  • 独立したコンポーネントが特定の機能を提供するサービスとして実装されている
• Publish-Subscribe
  • プロデューサーとコンシューマは独立して存在し、互いに認識しない
• 共有データ
  • 複数のコンポーネントで共通のデータストアを介してデータにアクセスするパターン
• 多層
  • 実行時の構造を論理的なグループにまとめる。設計時は、レイヤー。

意味のあるモデルで複雑さを扱う

物に名前を付けるには段階がある。(DDDのユビキタス言語を目指す)

モデルは、コードから分離されているという欠点を持つ。

アーキテクチャを記述する

• 考えを明確にする
  • 自分の知識と向き合い、分かっていること、分かっていると思っていること、そして分からないことを明らかにする

アーキテクチャに通知表をつける

アーキテクティングの最終的な成果はビジネスおよびステークホルダーの目標を満たすシステム設計して実装すること。

まとめ

• 「Design It!」を読んで学んだことをアウトプットした
• 時間ができた時に、勉強会開きたいので一緒にやる人募集！

Design It! ―プログラマーのためのアーキテクティング入門