Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

MinoDriven
February 10, 2023

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

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

MinoDriven

February 10, 2023
Tweet

More Decks by MinoDriven

Other Decks in Programming

Transcript

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

    View Slide

  2. こんにちは ミノ駆動です

    View Slide

  3. ここで働いています

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  10. クソデカ
    巨大クラス

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  20. 現実物体のあらゆる属性を盛り込む??
    商品
    売値
    発売日
    原価
    商品分類
    原材料
    構成部品
    匂い

    予約開始日
    製造メーカー
    重量
    サイズ
    製造者
    賞味期限
    発注金額
    在庫数

    View Slide

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

    View Slide

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

    発注金額
    在庫数
    注文品
    ID
    商品名
    売値
    在庫数
    抽出

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  26. 整理するには……

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  33. 目的 課題 解決手段

    View Slide

  34. 目的 課題 解決手段

    View Slide

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

    View Slide

  36. 抽象化の定義

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  40. その通り

    View Slide

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

    View Slide

  42. その謎を解くには

    View Slide

  43. 問題領域
    解決領域

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  64. 商品
    原材料
    構成部品
    匂い

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  70. 凝集度

    View Slide

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

    View Slide

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

    View Slide

  73. ユビキタス言語

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  79. ドメインエキスパート

    View Slide

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

    View Slide

  81. 単一責任原則 & DRY原則

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  87. 次回予告

    View Slide

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

    View Slide

  89. 乞うご期待

    View Slide

  90. ご清聴、ありがとうございました

    View Slide