はじめに
こんにちは
『はじめての設計をやり抜くための本』の社内向け輪読会の資料です。
以下の記事の続きになります。
今回で最後までやっていきます。
第5章 アーキテクチャの目的
前章で内部設計・外部設計について行いました。今回はアーキテクチャについてです。
まずアーキテクチャとはなにかですが、ISO/IEC/IEEE 42010の定義がよく引用されており、そこでは以下の様に定義されています。
(ISO/IEC/IEEE 42010は何度も改定されており、現行のものはISO/IEC/IEEE 42010:2022です)
システムのコンポーネント、コンポーネント同士と環境との間の関係、およびその設計と進化を支配する原理に体現された、システムの基本的な構造
アーキテクチャは開発者がつくるコンポーネント同士や環境との関係を表していると定義しています。
本書ではマイクロサービスを例に出して説明していますね。
アーキテクチャの効果は以下の6つあるそうです。
- 保守性の向上
- 合目的性の向上
- 見積もりへの応用
- 技術リスクの局所化
- ソースコード自動生成への応用
- フレームワークへの応用
重要となるのは1と2で他は副次的な効果です。
保守性の向上は直感的に理解できると思うので省きます。
2の合目的性の向上について簡単にまとめます。
合目的性の向上について
合目的性とは、ソフトウェアが機能要件を実現しているかということです。
つまり実装漏れが少なくなることをアーキテクチャの目的としています。
本書では、良いアーキテクチャならば、設計書からプログラムへのトレーサビリティが高くなるため、合目的性の向上につながると解説しています。
確かに良いコンポーネント設計は読みやすく、設計書の意図を組んだ設計がされていると思いますので改めて言語化されると納得できるはなしです。
その他効果について
その他効果についてで他をまとめますが、5.ソースコード自動生成への応用はいわゆるローコード開発の話で、昨今のcopilotなどを利用したソースコード生成の話で版ありません。
品質や保守性の問題も議論されており、採用する際は慎重に検討する必要がありそうです。
第6章 アーキテクチャ設計のアプローチ
アーキテクチャ設計するためには、開発するシステムの基本構造を知る必要があります。
(例でERPのパッケージソフトの追加開発の話していて少し親近感)
抽象化するとこんな感じ。
この4つのパターンの処理をどうするかと考えることがアーキテクトの役目です。
受信のプロトコルは何が良いのか、加工のトランザクションは対応するのか、保存はデーターベースにするのか、応答は何を返すのか、といった感じです。
アーキテクチャもまたオブジェクト指向設計でインターフェイスと実装の分離をすることも重要です。
(そのほうがアーキテクチャのベンダーロックも防げますしね)
他にアーキテクチャの設計として
- サブシステム分割
- レイヤーアーキテクチャ
以上を鑑みたアーキテクチャ設計について書かれています。
これらもシステムの複雑性をなくし、保守性を高めることを目的としています。
マイクロサービス
マイクロサービスもサブシステムと同じシステムを分割しますが、マイクロサービスは機能単位までサービスを分割し、徹底的に疎結合にすることいいます。
マイクロサービスの対義語としてすべてのサービスを一つにまとめることをモノリシックといいます。
モノリシックはコンポーネントが密結合になっており、保守性が下がるため避けたいものです。
MonorepoとPolyrepo
本書には書かれていませんが余談として。
マイクロサービスのソースコード管理として、マイクロサービスのサービスごとにリポジトリを分けるポリリポ、すべてのサービスを一つのリポジトリに管理するモノリポがあります。
マイクロサービスごとにチームに分かれて管理するのであればポリリポのほうが管理しやすく、密結合となるコードも書きづらいため採用するのもありなのかもしれません。
ただ、システム全体をビルド・デプロイする際に問題になったり、ひとつのチームでマイクロサービスを開発する場合、手間がかかります。
自分のチームは以前はポリリポでしたが、管理コストが高かったためモノリポにしたという経緯があります。
最近はマイクロサービスはモノリポで管理するのが流行りだそうです。
参考:https://zenn.dev/burizae/articles/c811cae767965a
第7章 本当に設計は必要か
設計についての本ですが、設計は不要である、といった意見も近年多く聞かれるようになったとのことでその解説を行っている章です。
設計が不要であるとの意見はアジャイル開発が注目されるようになり、顕著に見られるようになったとのことでした。
ここでアジャイル開発宣言を読んで見ましょう。
確かにアジャイル宣言には以下の文言が書かれています。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを
この文だけ読むと設計書を用意するのではなく、ソフトウェアの動作が正なのだから不要であるとの見方もできるのかもしれません。
ただし、最後にこう書かれています。
左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
つまりドキュメントは不要とは言っておらず、逆にドキュメントには価値があると言っています。
ただし、動くソフトウェアの方により価値をおくというだけです。
つまりアジャイル開発においてもドキュメントは必要です。
チームの合意や設計などをドキュメントに残しておくことは後から振り返るときに重要ですし、新しいメンバーが入ったときには理解の助けになります。
また、開発と保守でチームが異なる場合もドキュメントが重要です(そういったチームでアジャイル開発を行うのは困難だとは思いますが。。。)
設計のこれから
新人に設計を任せる場合、まず自分のチームでやっている開発手法を教えて、その後、アジャイル開発やウォーターフォール開発について教えて知見を広めるのが良いでしょう。
また、とにかくやってみて、議論して、チームにとって良い設計を考えてくことも大事です。
本書ではマーチン・ファウラー氏のIs Design Dead?を引用し、「進化的設計」と「計画的設計」の話をしています。
従来の設計は「計画的設計」で、設計が変わってしまうことは失敗を意味していました。
これからは「進化的設計」をし、システム開発の進捗に従って計画も進化させていこう、とのことでした。
終わりに
『はじめての設計をやり抜くための本』を読んでいきました。
この本には参考書籍が多く書かれており、設計のざっくりとした流れを掴み、詳細な解説は参考文献を読む、といった使い方が良さそうです。
また、開発の歴史の流れもある程度書かれており、新人が開発の流れを掴むには良いのかなと思います。
興味深い本でした。