目的と抽象化の関係性から分かる、システムの設計精度を高める考え方 / purpose abstraction design

2023/02/10、デブサミ2023の登壇資料です。
『目的と抽象化の関係性から分かる、システムの設計精度を高める考え方』
https://event.shoeisha.jp/devsumi/20230209/session/4182/

Transcript

1. 目的と抽象化の関係性から分かる システムの設計精度を高める考え方 Feb 10, 2023 @ Developers Summit 2023 READYFOR株式会社　ミノ駆動
2. こんにちは　ミノ駆動です
3. ここで働いています
4. 最近ニュースになったクラウドファンディング
5. 職歴とか今やってる仕事とか 大手電機メーカーなどで十数年組込み系、 2019年にWeb系へ移籍、 2021年4月にREADYFORにジョイン アプリケーションアーキテクトとして、 レガシーシステムのリファクタリングや 拡張性向上設計など、 システム設計に従事 ミノ駆動 @MinoDriven
6. 著作紹介 『良いコード／悪いコードで学ぶ設計入門』 技術的負債を作り込まない、 変更容易性の高い設計を学ぶ、 初級〜中級向け入門書。 新卒エンジニアに最適です。 輪読会も多数開催されております。 発売 10ヶ月で 8刷重版 発行部数 3万部 超え達成 3万部記念で 帯が付きました
7. 【本日のお話】 「目的−抽象化」の関係性に着目すると 設計の考え方が上手く整理される
8. モデル モデル モデル 本日の理解目標
9. 目的達成手段 目的達成手段 目的達成手段 本日の理解目標 モデルが目的達成手段に見えるようになることが 理解目標です
10. クソデカ 巨大クラス
11. クソデカ 巨大クラス 典型的な技術的負債ですね
12. 技術的負債の解消には…… 変更容易性を高める設計
13. 関心事Aの クラス 関心事Aの データ 関心事Aの ロジック 強く関連し合うもの同士を高凝集に
14. 関心事Aの クラス 関連の薄いものを疎結合に 関心事Bの クラス
15. 高凝集疎結合な設計を目指すと クラスはひとつひとつが小さく 適切な粒度に分割された構造になる クラス クラス クラス クラス クラス クラス
16. 【疑問】 ではクラスを分割する境界線は どう引けばいいんだろうか？
17. ボトムアップでクラスを構造化していく方法 私もよく用いる手法です ……でもそれだけで妥当なクラス構造を導出できるか？ ボトムアップだけでは限界 【例】 ある値に関する制約やドメインロジックを集め ValueObjectとしてカプセル化する
18. だから、適切な境界線を引くためのモデリング 注文品 受注明細 受注
19. 【疑問】 どういうことをするのがモデリングなのか？
20. 現実物体のあらゆる属性を盛り込む？？ 商品 売値 発売日 原価 商品分類 原材料 構成部品 匂い 味 予約開始日 製造メーカー 重量 サイズ 製造者 賞味期限 発注金額 在庫数
21. 商品 ID 商品名 原価 売値 サイズ 重量 商品分類 予約開始日 製造年月日 製造メーカー …… ……… 適切な分割が何もない巨大モデルになる 技術的負債になってしまう
22. システムの動作に必要な特徴だけを抽出する 一部分の側面だけを抽出することが抽象化 ………と呼ばれることが多い 商品 売値 発売日 商品名 原材料 構成部品 匂い 味 発注金額 在庫数 注文品 ID 商品名 売値 在庫数 抽出
23. ところがいざモデリングしてみると…… • 上手くモデリングできない • 実装との乖離が大きくなる といった状況に陥る場合がある 何が問題なのだろう？
24. 【提言】 「抽象化とは何か」が 整理されていないことが原因
25. 抽象化の考え方を整理する
26. 整理するには……
27. 【疑問】 そもそもシステムとは一体何か？
28. システムは目的達成手段 移動手段の一例 二足歩行も 立派なシステム 「〜〜したい」という目的を叶えるための目的達成手段がシステムである 上記例は「目的地へ移動したい」という目的を叶えるための移動手段 システムには必ず目的がある
29. 【目的】 商品を売買したい 【売買手段】 ECサイト 当然ソフトウェアも目的達成手段 【目的】 遊びたい 【娯楽手段】 ゲームソフト
30. 【目的達成手段】 システム 【目的達成手段】 モデル 【目的達成手段】 モデル 【目的達成手段】 モデル システムは目的達成手段であるから その構成要素たるモデルもまた目的達成手段である！！
31. ここから先は 「目的」という言葉に着目してください
32. 課題解決の考え方で基本かつ重要な 目的と課題の関係
33. 目的 課題 解決手段
34. 目的 課題 解決手段
35. • 目的が決まると課題が浮き彫りになる • 課題に対処するための解決手段が決まる • 目的が違うと課題も解決手段も違ってくる つまり と言える
36. 抽象化の定義
37. 【抽象化】 対象物に付随する様々な特徴のうち、 ある目的に合致した特徴のみを抜き出すこと(*1) (*1)『「具体⇄抽象」トレーニング 思考力が飛躍的にアップする 29問』 著:細谷功, PHPビジネス新書, p.97
38. 【抽象化】 対象物に付随する様々な特徴のうち、 目的達成する上で邪魔になる課題を抜き出すこと 目的と課題の関係に着目すると と言える
39. 【疑問】 ちょっと待て interfaceや抽象クラスを作るのも 抽象化と言わないか？
40. その通り
41. 抽象化には2つの意味がある
42. その謎を解くには
43. 問題領域 解決領域
44. 目的地に移動したい 自動車 飛行機 電車 問題領域 解決領域 問題領域に対し、それを解決するさまざまな 解決領域が世の中にはある
45. 課題の抽出 問題領域における 抽象化 動力源は？ エネルギーは？ 制御は？ 【解決領域】 自動車 電車 飛行機 << interface >> 移動手段 移動する() 解決領域における 抽象化 目的達成手段の抽象化 設計 【問題領域】 目的地に移動したい
46. 文脈によって抽象化の意味が異なる 【抽象化】 対象物に付随する様々な特徴のうち、 ある目的に合致した特徴のみを抜き出すこと(*1) (*1)『「具体⇄抽象」トレーニング 思考力が飛躍的にアップする 29問』 著:細谷功, PHPビジネス新書, p.97 【問題領域の抽象化】 対象物に付随する様々な特徴 のうち、目的達成する上で邪魔 になる課題を抜き出すこと 【解決領域の抽象化】 具体的なhowを削ぎ落とし、目 的の達成手段としての側面の みを抜き出すこと
47. ソフトウェア開発で「抽象化」と聞いたとき 問題領域と解決領域 どちらの抽象化なのか意識すると良い
48. 【問題領域】 【解決領域】 設計 【目的達成手段】 モデル 【目的達成手段】 interface 手段の抽象化 課題 目的 課題抽出(抽象化)
49. 【例題】 ピザのオンライン注文システムを開発する。 注文モデルはどうモデリングすればいいだろうか？ え？ 普通にECサイトと同じような 作りにすればいいんじゃないの？
50. ピザ注文時に発生しうる課題 • スタッフの調理キャパを超える注文数であっては困る • 食材の在庫量を超える注文数であっては困る • 注文数「−1」など、ありえない注文数になっては困る 単に注文モデルを作ればいいという話ではない 注文モデルは注文時の課題を解決する手段を 備えていなければならない
51. 課題の抽出 問題領域における 抽象化 調理キャパは？ 在庫量は？ 妥当な注文数は？ 【解決領域】 注文モデル 設計 【問題領域】 ピザを注文したい 課題を解決する仕組みを 備えるよう設計する
52. 注文 総注文数 注文日時 注文明細 注文数 注文品 売値 材料 追加() 削除() 追加(注文品) 削除(注文品) 1 * * 1 【総注文数の制約条件】 • スタッフの調理キャパ以内であること • 食材の在庫量以内であること • 1以上であること 【注文数の制約条件】 • 1以上であること こうした制約をカプセル化することで、 スタッフを守り、安全に注文を回せるシステムとなる
53. モデル データ 判断ロジック / 計算ロジック カプセル化 課題解決要素 目的達成手段 課題解決に必要な要素をカプセル化する これにより目的達成手段たるモデルが完成する
54. モデル データ 判断ロジック / 計算ロジック カプセル化 課題解決要素 目的達成手段 【補足】 DB設計に用いるデータモデルでは 判断／計算ロジックを持てない これがデータモデルとドメインモデルの決定的な違い
55. 【超重要】 ソフトウェアの目的を意識して 初めて抽象化できる、 モデリングできるようになる
56. 「目的−抽象化」の切り口で見ると 設計のさまざまな考えが整理される
57. 境界付けられたコンテキスト
58. 【目的】 商品を売買したい
59. 【大目的】 商品を売買したい 【中目的】 商品審査 したい 【中目的】 在庫管理 したい 【中目的】 注文 したい 【中目的】 配送 したい 大目的は中目的から構成される
60. 在庫管理 配送 注文 商品審査 ECサイト 商品モデル あらゆる目的に対応可能な、たったひとつの万能な 商品モデルはありえるのだろうか？？
61. クソコード動画「一枚岩モデル」 https://twitter.com/MinoDriven/status/1590181987910029314
62. 統一的な一枚岩モデルにより生じる弊害 • どの状況で何のデータが使われるのか分かりにくくなる • どの状況でどんな振る舞いが期待されるのか分かりにくくなる ◦ 状況によって守るべき不変条件が異なる • 言葉やデータの意味が多義的になり、混乱をきたす ◦ 混乱によりエンバグしやすい ◦ データのフォーマットが状況によって違うケースもある • 多くのあらゆるロジックと密結合になる ◦ 保守や仕様変更時の影響範囲分析に莫大な労力を要する
63. 在庫管理 配送 注文 商品審査 ECサイト 商品モデル 多くの目的をたったひとつのモデルで満たそうとすると さまざまな局面で支障をきたす！
64. 商品 原材料 構成部品 匂い 味 審査品目 品目分類 審査所見 審査結果 サイズ 重量 抽出 在庫品 発注金額 在庫量 安全在庫量 配送品 サイズ 重量 注文品 取扱開始日 売値 在庫量 取扱開始日 売値 在庫量 抽出 抽出 品目分類 審査所見 審査結果 抽出 発注金額 在庫量 安全在庫量 原価 予約開始日 製造メーカー 賞味期限 目的ごとにそれぞれ必要な解決要素を抽出
65. 在庫管理 配送 注文 商品審査 ECサイト 審査品目 品目分類 審査所見 審査結果 在庫品 発注金額 在庫量 安全在庫量 注文品 取扱開始日 売値 在庫量 配送品 サイズ 重量 商品は各目的に特化したモデルになる
66. 商品審査 サブシステム 注文 サブシステム 在庫管理 サブシステム 配送 サブシステム 審査品目 品目分類 審査所見 審査結果 在庫品 発注金額 在庫量 安全在庫量 注文品 取扱開始日 売値 在庫量 配送品 サイズ 重量 モデルの適用範囲が違うため目的単位でサブシステムに分割
67. 商品審査 審査コンテキスト 注文 注文コンテキスト 在庫管理 在庫管理コンテキスト 配送 配送コンテキスト 審査品目 品目分類 審査所見 審査結果 在庫品 発注金額 在庫量 安全在庫量 注文品 取扱開始日 売値 在庫量 配送品 サイズ 重量 分割したサブシステムこそが境界付けられたコンテキスト
68. 【DDDの境界付けられたコンテキスト】 中目的に対応する目的達成手段 つまり と言える
69. 【大目的】 商品を売買したい 【中目的】 商品審査 したい 【中目的】 在庫管理 したい 【中目的】 注文 したい 【中目的】 配送 したい 【目的達成手段】 審査 コンテキスト 【目的達成手段】 在庫管理 コンテキスト 【目的達成手段】 注文 コンテキスト 【目的達成手段】 配送 コンテキスト 大目的は中目的から構成されるコンポジション構造 各中目的に対応する達成手段としてのコンテキスト
70. 凝集度
71. 【凝集度】 モジュール内における、データとロジックの関係性の強さを表す 指標 どういう「関係性の強さ」か？ 「ある目的における関係性の強さ」と説明できる。 つまり、目的ごとに高凝集にし、目的が異なるものを疎結合にす るよう設計する。
72. 商品審査 審査コンテキスト 注文 注文コンテキスト 在庫管理 在庫管理コンテキスト 配送 配送コンテキスト 審査品目 品目分類 審査所見 審査結果 在庫品 発注金額 在庫量 安全在庫量 注文品 取扱開始日 売値 在庫量 配送品 サイズ 重量 目的ごとに 凝集している
73. ユビキタス言語
74. ユビキタス言語は目的を識別、共有するための言葉 • ユビキタス言語は各コンテキスト内部で有効な言葉。 • 同じ言葉でもコンテキストが違うと意味が異なる。 目的が違うから。 • つまり、ユビキタス言語とは目的と必ず紐付く言葉。 • コンテキストにおける目的を識別し、 チームと共有するための言葉。 • ゆえにユビキタス言語を策定する際は、 ソフトウェアの目的を必ず意識すること。 • 単なる用語集では目的が分からず、 モデリングやコンテキスト設計の役に立たない。
75. 意図の明白なインターフェース
76. 【意図の明白なインターフェース】 クラスと操作には、その効果と目的を記述する名前を付け、約 束したことを実行する手段には言及しないこと。（中略）こうした 名前にはユビキタス言語に従っていなければならない。(*2) (*2)『エリック・エヴァンスのドメイン駆動設計』著： Eric Evans、監訳：今関剛、訳：和智右桂、牧野祐子、 2011年刊 行、翔泳社、p.252
77. 商品審査 審査コンテキスト 注文 注文コンテキスト 在庫管理 在庫管理コンテキスト 配送 配送コンテキスト 審査品目 品目分類 審査所見 審査結果 在庫品 発注金額 在庫量 安全在庫量 注文品 取扱開始日 売値 在庫量 配送品 サイズ 重量 「商品」ではなく、目的に特化した名前を付ける
78. 【意図の明白なインターフェース】 クラスと操作には、その効果と目的を記述する名前を付け、約 束したことを実行する手段には言及しないこと。（中略）こうした 名前にはユビキタス言語に従っていなければならない。(*2) (*2)『エリック・エヴァンスのドメイン駆動設計』著： Eric Evans、監訳：今関剛、訳：和智右桂、牧野祐子、 2011年刊 行、翔泳社、p.252 ユビキタス言語が目的ベースであることが分かる。 目的ベースでの命名は、拙著『良いコード／悪いコードで学ぶ設 計入門』の目的駆動名前設計で詳しく解説。
79. ドメインエキスパート
80. ドメインエキスパートとは目的と課題を話し合う • ドメインエキスパート：ソフトウェアが解決したい事業領域につい て深い知識を持っている人 • ドメインエキスパートと協力してドメインモデリングするのがDDD のキモ • モデリング：目的→抽象化(課題抽出)→解決手段の設計 • 目的が決まって、初めて課題が浮き彫りになる。 • つまり、ドメインエキスパートとはただ漫然と話し合うのではなく、 事業目的と目的達成上の課題について話し合うことが、良きドメ インモデリングをする要となる。
81. 単一責任原則　＆　DRY原則
82. 通常割引価格 割引率5% 夏季割引価格 わたくしと同じ5%割引ですわ〜 おDRY原則に基づいて 再利用しますわ〜
83. 通常割引価格 割引率3% 夏季割引価格 3%割引に 仕様変更しますわ〜 きゃあああああ！！！！！ 5%割引の仕様を満たせなく なりましたわよ！？！？？ • 割引率が多目的に使われてしまっており 一方の仕様変更が別目的の仕様に影響を及ぼしてしまう • 典型的な単一責任原則違反 • DRY原則とはコードの重複を許さないのではなく 意図や目的の重複を許さない原則
84. 通常割引価格 割引率5% 夏季割引価格 割引率5% • 同じように見えるロジックでも 目的の異なるものを共通化してはならない • こうすることで 目的の異なるもの同士の仕様変更が影響しなくなる • 各クラスは多目的にならないよう 単一の目的を達成する手段として設計する • 単一責任原則とは単一目的原則
85. 他の設計原則や設計手法も 「目的−抽象化」の観点で見てみよう いろいろ発見があるはず
86. まとめ • システムとは目的達成手段であり、 システムの構成要素たるモデルも目的達成手段である • モデリングとは、 ◦ 目的の特定 ◦ 課題の洗い出し（問題領域における抽象化） ◦ 課題解決手段の設計 • 「目的−抽象化」の切り口で見てみると、 さまざまな設計原則や設計手法の考え方が整理される
87. 次回予告
88. 【問題領域】 【解決領域】 設計 【目的達成手段】 モデル 【目的達成手段】 interface 手段の抽象化 課題 目的 課題抽出(抽象化) 3/3 Forkwellさんのイベントでは interface設計について 解説します
89. 乞うご期待
90. ご清聴、ありがとうございました