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

by MinoDriven

Slide 1

Slide 1 text

目的と抽象化の関係性から分かるシステムの設計精度を高める考え方 Feb 10, 2023 @ Developers Summit 2023 READYFOR株式会社　ミノ駆動

Slide 2

Slide 2 text

こんにちは　ミノ駆動です

Slide 3

Slide 3 text

ここで働いています

Slide 4

Slide 4 text

最近ニュースになったクラウドファンディング

Slide 5

Slide 5 text

職歴とか今やってる仕事とか大手電機メーカーなどで十数年組込み系、 2019年にWeb系へ移籍、 2021年4月にREADYFORにジョインアプリケーションアーキテクトとして、レガシーシステムのリファクタリングや拡張性向上設計など、システム設計に従事ミノ駆動 @MinoDriven

Slide 6

Slide 6 text

著作紹介『良いコード／悪いコードで学ぶ設計入門』技術的負債を作り込まない、変更容易性の高い設計を学ぶ、初級〜中級向け入門書。新卒エンジニアに最適です。輪読会も多数開催されております。発売 10ヶ月で 8刷重版発行部数 3万部超え達成 3万部記念で帯が付きました

Slide 7

Slide 7 text

【本日のお話】「目的−抽象化」の関係性に着目すると設計の考え方が上手く整理される

Slide 8

Slide 8 text

モデルモデルモデル本日の理解目標

Slide 9

Slide 9 text

目的達成手段目的達成手段目的達成手段本日の理解目標モデルが目的達成手段に見えるようになることが理解目標です

Slide 10

Slide 10 text

クソデカ巨大クラス

Slide 11

Slide 11 text

クソデカ巨大クラス典型的な技術的負債ですね

Slide 12

Slide 12 text

技術的負債の解消には…… 変更容易性を高める設計

Slide 13

Slide 13 text

関心事Aのクラス関心事Aのデータ関心事Aのロジック強く関連し合うもの同士を高凝集に

Slide 14

Slide 14 text

関心事Aのクラス関連の薄いものを疎結合に関心事Bのクラス

Slide 15

Slide 15 text

高凝集疎結合な設計を目指すとクラスはひとつひとつが小さく適切な粒度に分割された構造になるクラスクラスクラスクラスクラスクラス

Slide 16

Slide 16 text

【疑問】ではクラスを分割する境界線はどう引けばいいんだろうか？

Slide 17

Slide 17 text

ボトムアップでクラスを構造化していく方法私もよく用いる手法です ……でもそれだけで妥当なクラス構造を導出できるか？ボトムアップだけでは限界【例】ある値に関する制約やドメインロジックを集め ValueObjectとしてカプセル化する

Slide 18

Slide 18 text

だから、適切な境界線を引くためのモデリング注文品受注明細受注

Slide 19

Slide 19 text

【疑問】どういうことをするのがモデリングなのか？

Slide 20

Slide 20 text

現実物体のあらゆる属性を盛り込む？？商品売値発売日原価商品分類原材料構成部品匂い味予約開始日製造メーカー重量サイズ製造者賞味期限発注金額在庫数

Slide 21

Slide 21 text

商品 ID 商品名原価売値サイズ重量商品分類予約開始日製造年月日製造メーカー …… ……… 適切な分割が何もない巨大モデルになる技術的負債になってしまう

Slide 22

Slide 22 text

システムの動作に必要な特徴だけを抽出する一部分の側面だけを抽出することが抽象化 ………と呼ばれることが多い商品売値発売日商品名原材料構成部品匂い味発注金額在庫数注文品 ID 商品名売値在庫数抽出

Slide 23

Slide 23 text

ところがいざモデリングしてみると…… ● 上手くモデリングできない ● 実装との乖離が大きくなるといった状況に陥る場合がある何が問題なのだろう？

Slide 24

Slide 24 text

【提言】「抽象化とは何か」が整理されていないことが原因

Slide 25

Slide 25 text

抽象化の考え方を整理する

Slide 26

Slide 26 text

整理するには……

Slide 27

Slide 27 text

【疑問】そもそもシステムとは一体何か？

Slide 28

Slide 28 text

システムは目的達成手段移動手段の一例二足歩行も立派なシステム「〜〜したい」という目的を叶えるための目的達成手段がシステムである上記例は「目的地へ移動したい」という目的を叶えるための移動手段システムには必ず目的がある

Slide 29

Slide 29 text

【目的】商品を売買したい【売買手段】 ECサイト当然ソフトウェアも目的達成手段【目的】遊びたい【娯楽手段】ゲームソフト

Slide 30

Slide 30 text

【目的達成手段】システム【目的達成手段】モデル【目的達成手段】モデル【目的達成手段】モデルシステムは目的達成手段であるからその構成要素たるモデルもまた目的達成手段である！！

Slide 31

Slide 31 text

ここから先は「目的」という言葉に着目してください

Slide 32

Slide 32 text

課題解決の考え方で基本かつ重要な目的と課題の関係

Slide 33

Slide 33 text

目的課題解決手段

Slide 34

Slide 34 text

目的課題解決手段

Slide 35

Slide 35 text

● 目的が決まると課題が浮き彫りになる ● 課題に対処するための解決手段が決まる ● 目的が違うと課題も解決手段も違ってくるつまりと言える

Slide 36

Slide 36 text

抽象化の定義

Slide 37

Slide 37 text

【抽象化】対象物に付随する様々な特徴のうち、ある目的に合致した特徴のみを抜き出すこと(*1) (*1)『「具体⇄抽象」トレーニング思考力が飛躍的にアップする 29問』著:細谷功, PHPビジネス新書, p.97

Slide 38

Slide 38 text

【抽象化】対象物に付随する様々な特徴のうち、目的達成する上で邪魔になる課題を抜き出すこと目的と課題の関係に着目するとと言える

Slide 39

Slide 39 text

【疑問】ちょっと待て interfaceや抽象クラスを作るのも抽象化と言わないか？

Slide 40

Slide 40 text

その通り

Slide 41

Slide 41 text

抽象化には2つの意味がある

Slide 42

Slide 42 text

その謎を解くには

Slide 43

Slide 43 text

問題領域解決領域

Slide 44

Slide 44 text

目的地に移動したい自動車飛行機電車問題領域解決領域問題領域に対し、それを解決するさまざまな解決領域が世の中にはある

Slide 45

Slide 45 text

課題の抽出問題領域における抽象化動力源は？エネルギーは？制御は？【解決領域】自動車電車飛行機 << interface >> 移動手段移動する() 解決領域における抽象化目的達成手段の抽象化設計【問題領域】目的地に移動したい

Slide 46

Slide 46 text

文脈によって抽象化の意味が異なる【抽象化】対象物に付随する様々な特徴のうち、ある目的に合致した特徴のみを抜き出すこと(*1) (*1)『「具体⇄抽象」トレーニング思考力が飛躍的にアップする 29問』著:細谷功, PHPビジネス新書, p.97 【問題領域の抽象化】対象物に付随する様々な特徴のうち、目的達成する上で邪魔になる課題を抜き出すこと【解決領域の抽象化】具体的なhowを削ぎ落とし、目的の達成手段としての側面のみを抜き出すこと

Slide 47

Slide 47 text

ソフトウェア開発で「抽象化」と聞いたとき問題領域と解決領域どちらの抽象化なのか意識すると良い

Slide 48

Slide 48 text

【問題領域】【解決領域】設計【目的達成手段】モデル【目的達成手段】 interface 手段の抽象化課題目的課題抽出(抽象化)

Slide 49

Slide 49 text

【例題】ピザのオンライン注文システムを開発する。注文モデルはどうモデリングすればいいだろうか？え？普通にECサイトと同じような作りにすればいいんじゃないの？

Slide 50

Slide 50 text

ピザ注文時に発生しうる課題 ● スタッフの調理キャパを超える注文数であっては困る ● 食材の在庫量を超える注文数であっては困る ● 注文数「−1」など、ありえない注文数になっては困る単に注文モデルを作ればいいという話ではない注文モデルは注文時の課題を解決する手段を備えていなければならない

Slide 51

Slide 51 text

課題の抽出問題領域における抽象化調理キャパは？在庫量は？妥当な注文数は？【解決領域】注文モデル設計【問題領域】ピザを注文したい課題を解決する仕組みを備えるよう設計する

Slide 52

Slide 52 text

注文総注文数注文日時注文明細注文数注文品売値材料追加() 削除() 追加(注文品) 削除(注文品) 1 * * 1 【総注文数の制約条件】 ● スタッフの調理キャパ以内であること ● 食材の在庫量以内であること ● 1以上であること【注文数の制約条件】 ● 1以上であることこうした制約をカプセル化することで、スタッフを守り、安全に注文を回せるシステムとなる

Slide 53

Slide 53 text

モデルデータ判断ロジック / 計算ロジックカプセル化課題解決要素目的達成手段課題解決に必要な要素をカプセル化するこれにより目的達成手段たるモデルが完成する

Slide 54

Slide 54 text

モデルデータ判断ロジック / 計算ロジックカプセル化課題解決要素目的達成手段【補足】 DB設計に用いるデータモデルでは判断／計算ロジックを持てないこれがデータモデルとドメインモデルの決定的な違い

Slide 55

Slide 55 text

【超重要】ソフトウェアの目的を意識して初めて抽象化できる、モデリングできるようになる

Slide 56

Slide 56 text

「目的−抽象化」の切り口で見ると設計のさまざまな考えが整理される

Slide 57

Slide 57 text

境界付けられたコンテキスト

Slide 58

Slide 58 text

【目的】商品を売買したい

Slide 59

Slide 59 text

【大目的】商品を売買したい【中目的】商品審査したい【中目的】在庫管理したい【中目的】注文したい【中目的】配送したい大目的は中目的から構成される

Slide 60

Slide 60 text

在庫管理配送注文商品審査 ECサイト商品モデルあらゆる目的に対応可能な、たったひとつの万能な商品モデルはありえるのだろうか？？

Slide 61

Slide 61 text

クソコード動画「一枚岩モデル」 https://twitter.com/MinoDriven/status/1590181987910029314

Slide 62

Slide 62 text

統一的な一枚岩モデルにより生じる弊害 ● どの状況で何のデータが使われるのか分かりにくくなる ● どの状況でどんな振る舞いが期待されるのか分かりにくくなる ○ 状況によって守るべき不変条件が異なる ● 言葉やデータの意味が多義的になり、混乱をきたす ○ 混乱によりエンバグしやすい ○ データのフォーマットが状況によって違うケースもある ● 多くのあらゆるロジックと密結合になる ○ 保守や仕様変更時の影響範囲分析に莫大な労力を要する

Slide 63

Slide 63 text

在庫管理配送注文商品審査 ECサイト商品モデル多くの目的をたったひとつのモデルで満たそうとするとさまざまな局面で支障をきたす！

Slide 64

Slide 64 text

商品原材料構成部品匂い味審査品目品目分類審査所見審査結果サイズ重量抽出在庫品発注金額在庫量安全在庫量配送品サイズ重量注文品取扱開始日売値在庫量取扱開始日売値在庫量抽出抽出品目分類審査所見審査結果抽出発注金額在庫量安全在庫量原価予約開始日製造メーカー賞味期限目的ごとにそれぞれ必要な解決要素を抽出

Slide 65

Slide 65 text

在庫管理配送注文商品審査 ECサイト審査品目品目分類審査所見審査結果在庫品発注金額在庫量安全在庫量注文品取扱開始日売値在庫量配送品サイズ重量商品は各目的に特化したモデルになる

Slide 66

Slide 66 text

商品審査サブシステム注文サブシステム在庫管理サブシステム配送サブシステム審査品目品目分類審査所見審査結果在庫品発注金額在庫量安全在庫量注文品取扱開始日売値在庫量配送品サイズ重量モデルの適用範囲が違うため目的単位でサブシステムに分割

Slide 67

Slide 67 text

商品審査審査コンテキスト注文注文コンテキスト在庫管理在庫管理コンテキスト配送配送コンテキスト審査品目品目分類審査所見審査結果在庫品発注金額在庫量安全在庫量注文品取扱開始日売値在庫量配送品サイズ重量分割したサブシステムこそが境界付けられたコンテキスト

Slide 68

Slide 68 text

【DDDの境界付けられたコンテキスト】中目的に対応する目的達成手段つまりと言える

Slide 69

Slide 69 text

【大目的】商品を売買したい【中目的】商品審査したい【中目的】在庫管理したい【中目的】注文したい【中目的】配送したい【目的達成手段】審査コンテキスト【目的達成手段】在庫管理コンテキスト【目的達成手段】注文コンテキスト【目的達成手段】配送コンテキスト大目的は中目的から構成されるコンポジション構造各中目的に対応する達成手段としてのコンテキスト

Slide 70

Slide 70 text

凝集度

Slide 71

Slide 71 text

【凝集度】モジュール内における、データとロジックの関係性の強さを表す指標どういう「関係性の強さ」か？「ある目的における関係性の強さ」と説明できる。つまり、目的ごとに高凝集にし、目的が異なるものを疎結合にするよう設計する。

Slide 72

Slide 72 text

商品審査審査コンテキスト注文注文コンテキスト在庫管理在庫管理コンテキスト配送配送コンテキスト審査品目品目分類審査所見審査結果在庫品発注金額在庫量安全在庫量注文品取扱開始日売値在庫量配送品サイズ重量目的ごとに凝集している

Slide 73

Slide 73 text

ユビキタス言語

Slide 74

Slide 74 text

ユビキタス言語は目的を識別、共有するための言葉 ● ユビキタス言語は各コンテキスト内部で有効な言葉。 ● 同じ言葉でもコンテキストが違うと意味が異なる。目的が違うから。 ● つまり、ユビキタス言語とは目的と必ず紐付く言葉。 ● コンテキストにおける目的を識別し、チームと共有するための言葉。 ● ゆえにユビキタス言語を策定する際は、ソフトウェアの目的を必ず意識すること。 ● 単なる用語集では目的が分からず、モデリングやコンテキスト設計の役に立たない。

Slide 75

Slide 75 text

意図の明白なインターフェース

Slide 76

Slide 76 text

Slide 77

Slide 77 text

商品審査審査コンテキスト注文注文コンテキスト在庫管理在庫管理コンテキスト配送配送コンテキスト審査品目品目分類審査所見審査結果在庫品発注金額在庫量安全在庫量注文品取扱開始日売値在庫量配送品サイズ重量「商品」ではなく、目的に特化した名前を付ける

Slide 78

Slide 78 text

【意図の明白なインターフェース】クラスと操作には、その効果と目的を記述する名前を付け、約束したことを実行する手段には言及しないこと。（中略）こうした名前にはユビキタス言語に従っていなければならない。(*2) (*2)『エリック・エヴァンスのドメイン駆動設計』著： Eric Evans、監訳：今関剛、訳：和智右桂、牧野祐子、 2011年刊行、翔泳社、p.252 ユビキタス言語が目的ベースであることが分かる。目的ベースでの命名は、拙著『良いコード／悪いコードで学ぶ設計入門』の目的駆動名前設計で詳しく解説。

Slide 79

Slide 79 text

ドメインエキスパート

Slide 80

Slide 80 text

ドメインエキスパートとは目的と課題を話し合う ● ドメインエキスパート：ソフトウェアが解決したい事業領域について深い知識を持っている人 ● ドメインエキスパートと協力してドメインモデリングするのがDDD のキモ ● モデリング：目的→抽象化(課題抽出)→解決手段の設計 ● 目的が決まって、初めて課題が浮き彫りになる。 ● つまり、ドメインエキスパートとはただ漫然と話し合うのではなく、事業目的と目的達成上の課題について話し合うことが、良きドメインモデリングをする要となる。

Slide 81

Slide 81 text

単一責任原則　＆　DRY原則

Slide 82

Slide 82 text

通常割引価格割引率5% 夏季割引価格わたくしと同じ5%割引ですわ〜おDRY原則に基づいて再利用しますわ〜

Slide 83

Slide 83 text

通常割引価格割引率3% 夏季割引価格 3%割引に仕様変更しますわ〜きゃあああああ！！！！！ 5%割引の仕様を満たせなくなりましたわよ！？！？？ ● 割引率が多目的に使われてしまっており一方の仕様変更が別目的の仕様に影響を及ぼしてしまう ● 典型的な単一責任原則違反 ● DRY原則とはコードの重複を許さないのではなく意図や目的の重複を許さない原則

Slide 84

Slide 84 text

通常割引価格割引率5% 夏季割引価格割引率5% ● 同じように見えるロジックでも目的の異なるものを共通化してはならない ● こうすることで目的の異なるもの同士の仕様変更が影響しなくなる ● 各クラスは多目的にならないよう単一の目的を達成する手段として設計する ● 単一責任原則とは単一目的原則

Slide 85

Slide 85 text

他の設計原則や設計手法も「目的−抽象化」の観点で見てみよういろいろ発見があるはず

Slide 86

Slide 86 text

まとめ ● システムとは目的達成手段であり、システムの構成要素たるモデルも目的達成手段である ● モデリングとは、 ○ 目的の特定 ○ 課題の洗い出し（問題領域における抽象化） ○ 課題解決手段の設計 ● 「目的−抽象化」の切り口で見てみると、さまざまな設計原則や設計手法の考え方が整理される

Slide 87

Slide 87 text

次回予告

Slide 88

Slide 88 text

【問題領域】【解決領域】設計【目的達成手段】モデル【目的達成手段】 interface 手段の抽象化課題目的課題抽出(抽象化) 3/3 Forkwellさんのイベントでは interface設計について解説します