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