正しいものを正しく作る塾の設計コース第2回のまとめ
設計コース2回めを受けてからだいぶ時間が空いてしまいましが、2回めの内容のまとめと自分なりのメモを取っていたので、噛み砕き反芻するための記事とします。また、3回めを受けた後にまとめているので、3回目の内容を含みながらの考察になります。自分のためにまとめたので、本文はですます調ではなくなってしまって読みにくいと思いますが、ご容赦願います。
設計コースでの参考にする書籍3冊の設計アプローチ
設計コースでは下記3冊の内容に触れながらコースが進められる。
第2回の最初の内容では上記3冊の設計アプローチについての説明があった。
ソフトウェアシステムアーキテクチャ構築の原理
特定の設計アプローチを取り扱っているわけではなく、設計における課題を体系的に整理し、様々なアプローチを列挙している本。故に、最初から最後まで通して読む本ではなく、必要になった時に適宜どのようなアプローチがあるのか参照してゆく本。
エリック・エヴァンスのドメイン駆動設計
ソフトウェアの成長に重きを置いて振り切っている内容の本。アプリケーション全体を作る場合はエヴァンス本だけでは作れない。
オブジェクト指向入門 第2版 原則・コンセプト
作者がカテゴライズマニアを自称しており、書き方にもそれが出ている本。正確性と拡張性が重要視され、それを念頭に置いて読むことがポイントとなる。正確性と拡張性を実現するためにオブジェクト指向を使い、型・クラス・モジュールを一致させるべきと主張している。
考察
おそらく俯瞰するスキルを活用し、インプットの効果を上げることを狙いとしている部分。
設計の関心事（ユーザーインターフェースとデータベースの扱い）
アプリケーションの実現にはユーザーインターフェースとデータベースは必要な要素。
しかし、SSAでは様々な要素のうちの1つでしか無いし、DDDとOOSCではソフトウェアの中核の周りにある、周辺的で従属的な関心ごととして扱われている。
UIやDBは設計の中心課題ではない。
考察
ここは講師の増田さんの経験知からくる特徴的な部分。ここの考えが合わないとこの設計コースでの内容が入ってこなくなるかつ、重要な部分であるため記載されていると考えられる。
設計コースの3回目の内容と繋がっているのもこのスライドの部分で、３回目ではエヴァンス本の１章の内容を扱った。１章のp12には次のような内容が出てくる。
そこで、自動テストフレームワークを使って、非常にシンプルなプロトタイプを作成した。インフラストラクチャ部分は全て省いた。したがって、永続化もなければ、ユーザーインターフェース（UI）もない。これでふるまいだけに集中することができるようになった。その後、ほんの数日のうちに、簡単なプローブシミュレーションを実演することができた。
このようにエヴァンス本では、明確にUIやデータベースを使わずにソフトウェアの構築を始めている。
要点の見極め方
- まとめの段落（書き始め、もしくは最後の段落）から読み始めると理解が進みやすい。
- 一覧項目は最初がもっとも基本的で重要。順不同ではなく、均一ではない。
- 何度も登場する言葉が重要な関心ごとであり、作者が伝えたいこと。
論文や論理的な文章ほどそうなっている。
考察
効率的な文章の読み方についてまとめられたスライド。
DDDやOOSCは厚い本なので、意識的に実践し効率的に読んでいきたい。
3冊をつなぐ軸
- 望ましい品質
- ソフトウェア変更の背景と動機
- 変更を容易にする設計技法
- 変更を重視する開発プロセス
1.望ましい品質
- SSA２８章 変更容易性
- あらゆるシステムが経験する避けようのない変更に柔軟であり、そういう柔軟性を提供するコストに釣り合うシステムの能力
- DDD 進化を続けるソフトウェア
- （まえがき）いずれも役に立ったが、企業の継続的な要求をみたすべく進化し続けるソフトウェアをつくりだせたプロジェクトは一つだけ
- （最後の段落）成長するにつれて我々の進路をふさぐことなく、新しい機械を生み出し所有者にとって価値を付け加え続けるソフトウェア
- OOSC 拡張性
- （1.2.3拡張性）使用の変更に対するソフトウェア製品の適応のしやすさ
考察
設計コースにおける前提、最も大切な品質特性は発展性の論拠となる箇所。
３冊とも異なる切り口で変更容易性、発展性を論じている。
変更容易性が無ければソフトウェアは次第に使われなくなる経験と実感があり、納得する。そもそも変更や発展できるからこそ「ソフトウェア」と呼ばれるのではないだろうか。
2.ソフトウェア変更の背景と動機
- SSA:製品管理(PdM)
- （28.2関心事の1.製品管理）顧客のニーズと事情がもたらす機会と脅威が、ソフトウェアのすべての変更の文脈と方向性を提供する。（ビジネスがソフトウェア変更の文脈と方向性を決める）
- DDD:事業活動そのもの
- （まえがき）複雑なのはユーザーの活動やビジネス。これがソフトウェアの中心的な側面。設計を成功させ、変更や拡張を容易で安全にするために、この中心的側面を体系的に扱う。
- OOSC:外界の世界の変化
- （1.3ソフトウェアの保守）まっとうな保守作業は修正であり、外界の世界の変化を反映させること。
事業の知識をもとにして設計判断をしてゆく
考察
事業の目的、目標、方針があり、それらをソフトウェアがサポートするため、ビジネスを中心とすることはごく自然なことだと感じられる。ソフトウェア側の都合がビジネス側に影響を及ぼすことはあってはならないと思う。
3.変更を容易にする設計技法
- SSA:変更を閉じ込める
- （２８．４．１変更の阻止）変更の影響を局所化する設計の一般原則。カプセル化・関心事の分離・機能的凝集。単一の定義ポイント
- DDD:オブジェクト指向
- （まえがき）オブジェクトコミュニティの設計哲学、オブジェクト指向モデリング、オブジェクト指向設計についてのなんらかの知識
- OOSC：クラス・抽象データ型・モジュール
- ２．２方法論と言語
考察
3冊とも変更を容易にするためにオブジェクト指向に注目している。
DDDでは確かにオブジェクト指向について具体的に論じられている箇所は無いと思うが、例えば下記の箇所
1章 知識豊富な設計 オーバーブッキングのルールは、ポリシーである。ポリシーとは、ストラテジーとして知られている設計パターンの別名だ（Gamma 他 1995）
この箇所で出てきている"ストラテジー"は明らかにGoFのデザインパターンのストラテジーパターンを指している。目次からも読み取れる。
SSA：変更を閉じ込める設計原則
- カプセル化
- 関心事の分離
- 機能的凝集
- 機能を入出力と考えると、手続き的な凝集。機能を値の種類ごとの計算・判断ロジックの集合と考えるとオブジェクト指向プログラミングの凝集。
- 単一の定義ポイント
- 手続き的な設計では実現が難しい。オブジェクト指向プログラミングの重要原則。
考察
こちらのブログ記事を設計コース用にまとめてもらったようなスライド。
カプセル化とデータ抽象の違いを理解できていない。
4.変更を重視する開発プロセス
- SSA:選択肢のひとつとしてアジャイル
- (28.2.6変更の対価を払う時期)前払いと後払いの両極端の間でバランスを取る
- DDD:アジャイルにおける設計の重要性
- 開発者が括弧とした設計原則を持っていないと、理解も変更も難しい、アジャイルとは正反対のソフトウェアを作り出してしまう。XP（エクストリームプログラミング）は設計に関する鋭いセンスを持った開発者に適している。
- OOSC：一貫した方法論（オブジェクト指向）を適用する
- ライフサイクル全体（分析・設計・実装・保守）に適用し、作業感の隔たりを最小に。
考察
アジャイルやXPについての知識が不足していると感じたスライド。アジャイルソフトウェア開発の奥義を借りることが出来たので、DDDの後に読む。
このスライドの後にウォーターフォールとアジャイルなアプローチとの比較のスライドがあった。
ウォーターフォールはシステマチックな面は良いが、現代では費用対効果が悪くなりすぎると増田さんは主張されていた。
しかしそれと同時にアジャイルなアプローチならうまくいくのかというとそんなことはなく、高い設計スキルが必要になってくるという話もあった。
経験として設計スキルは大切であると感じていた部分を言語化してもらえたと感じた。
まとめ
設計アプローチの選択がテーマの回だった。設計の重要な関心事はビジネスであり、UIやDBではないという部分が際立った回だと思う。
大きくまとめると、ソフトウェアの発展性を重視して、ビジネスを主軸にソフトウェアを組み立て、オブジェクト指向で変更を容易にするというアプローチをしている。そのために必要になるのが設計スキル。
どの内容もとても大切な内容だったが、概要の部分が多かった。しかしこの内容を念頭に置いてDDDやOOSCなどを読み込んでいけば、格段に知識の吸収力が良くなると思う。
次回は第4回だが、その前に第3回の内容もまとめたいと思う。
