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. 現実物体のあらゆる属性を盛り込む?? 商品 売値 発売日 原価 商品分類 原材料 構成部品 匂い 味

    予約開始日 製造メーカー 重量 サイズ 製造者 賞味期限 発注金額 在庫数
  2. 商品 ID 商品名 原価 売値 サイズ 重量 商品分類 予約開始日 製造年月日

    製造メーカー …… ……… 適切な分割が何もない巨大モデルになる 技術的負債になってしまう
  3. 課題の抽出 問題領域における 抽象化 動力源は? エネルギーは? 制御は? 【解決領域】 自動車 電車 飛行機

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

    【問題領域の抽象化】 対象物に付随する様々な特徴 のうち、目的達成する上で邪魔 になる課題を抜き出すこと 【解決領域の抽象化】 具体的なhowを削ぎ落とし、目 的の達成手段としての側面の みを抜き出すこと
  5. 注文 総注文数 注文日時 注文明細 注文数 注文品 売値 材料 追加() 削除()

    追加(注文品) 削除(注文品) 1 * * 1 【総注文数の制約条件】 • スタッフの調理キャパ以内であること • 食材の在庫量以内であること • 1以上であること 【注文数の制約条件】 • 1以上であること こうした制約をカプセル化することで、 スタッフを守り、安全に注文を回せるシステムとなる
  6. モデル データ 判断ロジック / 計算ロジック カプセル化 課題解決要素 目的達成手段 【補足】 DB設計に用いるデータモデルでは

    判断/計算ロジックを持てない これがデータモデルとドメインモデルの決定的な違い
  7. 統一的な一枚岩モデルにより生じる弊害 • どの状況で何のデータが使われるのか分かりにくくなる • どの状況でどんな振る舞いが期待されるのか分かりにくくなる ◦ 状況によって守るべき不変条件が異なる • 言葉やデータの意味が多義的になり、混乱をきたす ◦

    混乱によりエンバグしやすい ◦ データのフォーマットが状況によって違うケースもある • 多くのあらゆるロジックと密結合になる ◦ 保守や仕様変更時の影響範囲分析に莫大な労力を要する
  8. 商品 原材料 構成部品 匂い 味 審査品目 品目分類 審査所見 審査結果 サイズ

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

    発注金額 在庫量 安全在庫量 注文品 取扱開始日 売値 在庫量 配送品 サイズ 重量 商品は各目的に特化したモデルになる
  10. 商品審査 サブシステム 注文 サブシステム 在庫管理 サブシステム 配送 サブシステム 審査品目 品目分類

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

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

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

    審査所見 審査結果 在庫品 発注金額 在庫量 安全在庫量 注文品 取扱開始日 売値 在庫量 配送品 サイズ 重量 目的ごとに 凝集している
  14. ユビキタス言語は目的を識別、共有するための言葉 • ユビキタス言語は各コンテキスト内部で有効な言葉。 • 同じ言葉でもコンテキストが違うと意味が異なる。 目的が違うから。 • つまり、ユビキタス言語とは目的と必ず紐付く言葉。 • コンテキストにおける目的を識別し、

    チームと共有するための言葉。 • ゆえにユビキタス言語を策定する際は、 ソフトウェアの目的を必ず意識すること。 • 単なる用語集では目的が分からず、 モデリングやコンテキスト設計の役に立たない。
  15. 商品審査 審査コンテキスト 注文 注文コンテキスト 在庫管理 在庫管理コンテキスト 配送 配送コンテキスト 審査品目 品目分類

    審査所見 審査結果 在庫品 発注金額 在庫量 安全在庫量 注文品 取扱開始日 売値 在庫量 配送品 サイズ 重量 「商品」ではなく、目的に特化した名前を付ける
  16. ドメインエキスパートとは目的と課題を話し合う • ドメインエキスパート:ソフトウェアが解決したい事業領域につい て深い知識を持っている人 • ドメインエキスパートと協力してドメインモデリングするのがDDD のキモ • モデリング:目的→抽象化(課題抽出)→解決手段の設計 •

    目的が決まって、初めて課題が浮き彫りになる。 • つまり、ドメインエキスパートとはただ漫然と話し合うのではなく、 事業目的と目的達成上の課題について話し合うことが、良きドメ インモデリングをする要となる。
  17. 通常割引価格 割引率3% 夏季割引価格 3%割引に 仕様変更しますわ〜 きゃあああああ!!!!! 5%割引の仕様を満たせなく なりましたわよ!?!?? • 割引率が多目的に使われてしまっており

    一方の仕様変更が別目的の仕様に影響を及ぼしてしまう • 典型的な単一責任原則違反 • DRY原則とはコードの重複を許さないのではなく 意図や目的の重複を許さない原則
  18. まとめ • システムとは目的達成手段であり、 システムの構成要素たるモデルも目的達成手段である • モデリングとは、 ◦ 目的の特定 ◦ 課題の洗い出し(問題領域における抽象化)

    ◦ 課題解決手段の設計 • 「目的−抽象化」の切り口で見てみると、 さまざまな設計原則や設計手法の考え方が整理される
  19. 【問題領域】 【解決領域】 設計 【目的達成手段】 モデル 【目的達成手段】 interface 手段の抽象化 課題 目的

    課題抽出(抽象化) 3/3 Forkwellさんのイベントでは interface設計について 解説します