はむはむエンジニアぶろぐ

プログラミングやファイナンスや健康や目標設定などを中心にブログを書いてます

Clean Architecture読書会 Vol.2を開催した

Clean Architecture読書会 Vol.2を開催した。

Clean Architectureは洋書で英文onlyなのだが、リーダブルードの翻訳でおなじみの 角征典 さんが現在、翻訳の執筆作業中で勉強会参加者は翻訳リポジトリに参加できます!!(๑•̀ㅂ•́)و✧

勉強会参加者は特典で、世の中に出版される前の生原稿をみることが出来ます。
すごくオトクな勉強会となっております\(^o^)/

次回、Clean Architecture読書会 Vol.3 もよろしくお願いいたします!!

以下、今回のvol.2勉強会の内容のまとめになります。

Part V: Architecture

Chapter 15: What Is Architecture?(アーキテクチャとは?)

  • ソフトウェアアーキテクトはプログラマである
    • アーキテクチャの設計をするだけでなく、コードを書き続ける必要がある
  • ソフトウェアアーキテクチャは、システムの開発、デプロイ、運用、保守を容易にすること
    • 容易にするためには、できるだけ長い期間、多くの選択肢を残すこと
  • ソフトウェアアーキテクチャの目標は、システムのメンテナンスコストを最小限に抑えてプログラマの生産性を最大にすること
  • よいソフトウェアアーキテクチャは、システムを開発しやすくする
  • コストが、開発、デプロイ、保守に偏っている
    • インフラの運用より人件費のほうが高い
  • ソフトウェアは、「方針」(policy)と「詳細」(detail)にわけれる
    • 方針: ビジネスルール(ロジック)
    • 詳細: デバイス、DB、Webサーバ、フレームワーク、プロトコルなど
  • 詳細の決定を「延期」や「留保」することができる
    • DBは詳細なので開発の初期に決めることはない
  • 優秀なアーキテクトは決定をできるだけ長く遅延あるいは変更できるようにする

Chapter 16: Independence(独立性)

  • UIとビジネスルールと技術的詳細(DBやサーバなど)を分離する
    • それぞれの部分を独立して変更出来るようになる
    • UIを変更する理由は、ビジネスルールや技術的詳細を変更する理由とは関係がない
  • ユースケースも分離する
    • 注文を追加するユースケースと注文を削除するユースケースは分離しておくと影響を受けずに個別で変更できる
  • ユースケースが分離されていれば、ユースケースごとにチームで独立した開発ができる

Chapter 17: Boundaries: Drawing Lines(バウンダリー:境界線を引く)

  • 境界線を引く
    • DBはGUIにとって重要ではないので境界線を引く
    • DBはビジネスルールにとって重要ではないので境界線を引く
  • プラグインアーキテクチャ
    • ビジネスルールはコアで、ビジネスルールにプラグイン(GUIやDB)を当てるイメージ
    • プラグインは、代替え可能である MySQLからNoSQLなど

参加者の声

  • パンチカードの例など分かりにくい
  • 変更の先延ばしは、いつまで許されるのか?
  • 新規事業やスタートアップはAWSや特定のツールに依存したモデルになる(働く人の触れる技術が特定のものに依存している)
  • 通信系はユースケースが多く、ドメイン層は薄くなるので、クリーンアーキテクチャに適さないのではないか

他にも色々、議論がされていたがメモるの忘れた(´・ω・`)w
是非、Clean Architecture読書会 Vol.3 に参加して確かめてください。