設計の考え方とやり方

#asken_dev「設計の考え方とやり方」勉強会
https://asken.connpass.com/event/254709/

・良い設計は悪い設計より変更が楽で安全である
・ドメインモデル方式のクラス設計
・イミュータブル方式のテーブル設計
・設計スキルの身につけかた
・設計のためのモデリング

Transcript

1. 設計の考え方とやり方 2022年8月3日 有限会社システム設計 増田 亨 初版:2022/2/3 改訂:2022/8/3
2. 自己紹介 アプリケーション開発者 Java/Springを使った業務系アプリケーション開発 「ドメイン駆動設計」の開発現場への導入・実践 著書『現場で役立つシステム設計の原則』 ～変更を楽で安全にするオブジェクト指向の実践技法 技術者コミュニティ「現場から学ぶモデル駆動の設計」主催 2022/8/3 2
3. お話すること 良い設計を目指す 設計スタイルの選択 • クラス設計 • テーブル設計 • 開発のやり方 設計スキルを身につける 2022/8/3 3
4. 良い設計を目指す 2022/8/3 4
5. 良い設計は悪い設計より 変更が楽で安全である 2022/8/3 5
6. ソフトウェアを変更する理由（複合） • 市場の競合関係（競争優位・競争劣位）の変化に対応する • 事業の環境（社会経済や消費行動）の変化に適応する • 事業の遂行能力（組織・人材・仕事のやり方）を変える • 事業の方針を変える • 開発者の事業活動の理解が変わる • 開発者の設計能力が変わる • 利用できる技術の費用対効果が変わる（メモリ、帯域、…） 2022/8/3 6
7. ソフトウェアの変更が楽で安全であれば • 事業活動の変化のスピードを上げられる • 事業活動の変化のコストを下げられる • 開発者の学びと成長をソフトウェアに反映できる • 開発者の成長の機会を増やせる • 費用対効果の高い技術に移行できる 2022/8/3 7
8. ソフトウェアの変更がやっかいで危険になると • 事業活動の変化のスピードを落とす • 事業活動の変化のコストが増える • 開発者の成長の機会が減る • 開発者の学びと成長をソフトウェア開発に活かせない • 費用対効果の悪い技術を使い続ける 2022/8/3 8
9. 変更が楽で安全になる設計 それが開発者がやるべき仕事 私が実践している設計の考え方とやり方は、この価値観に基づいている 2022/8/3 9
10. 2022/8/3 10 設計スタイルの選択 クラス設計のスタイル テーブル設計のスタイル 開発のやり方 ソフトウェアの変更を楽で安全にするための
11. アプリケーション開発の今昔 かつての潮流 • トランザクションスクリプト方式 • 上書き更新型のデータベース • 目標固定の分解思考（ウォーターフォール） 今後の潮流 • ドメインモデル方式 • 追記型のデータベース • 目標可変の組み立て思考（アジャイル） 2022/8/3 11 手続き的なプログラミング SELECT FOR UPDATE エクセル仕様書 オブジェクト指向プログラミング (型・カプセル化・契約による設計） イベントソーシング/マイクロサービス IDE/git/CI-CD/コンテナ/XaaS
12. クラス設計のスタイル 2022/8/3 12 ソフトウェアの変更を楽で安全にするための
13. クラス設計の分かれ道 トランザクションスクリプト方式 • データクラスと機能クラスを分ける • 中核の関心事は入出力処理（画面・データベース・Web API） • プリミティブな型でプログラミング • 防御的プログラミング（ ドメインモデル方式 • ロジックをデータを一つのクラスにカプセル化する • 中核の関心事は計算判断ロジック（ビジネスルール） • アプリケーションで扱う値を独自の型として定義 • 契約プログラミング 2022/8/3 13
14. なぜドメインモデル方式か？ ソフトウェアの複雑になる主な理由は、ビジネスルールに基づく 計算判断ロジックの記述が複雑だから 計算判断ロジックの複雑さをどう扱うか？ トランザクションスクリプト方式の問題 • あちこちのデータ入出力処理に計算判断ロジックが断片化し重複する • ビジネスルールの暗号化 例えば if ( 区分 == 9 ) 処理数 = -1; • どこにどんな計算判断ロジックが書いてあるか探しにくい • ちょっとした計算判断ロジックの変更がやっかいで危険になる 2022/8/3 14
15. ドメインモデル方式 計算判断ロジック中心（ビジネスルール中心） 関連する業務ロジックと業務データを一つのクラスにカプセル化 • 同じデータを使った計算判断ロジックがあちこちに断片化しない／重複しない クラス名（型名）とメソッド名で業務の約束事を表現 • ビジネスで扱うデータの種類ごとにクラスを用意する • データの種類ごとに必要な計算判断を洗い出して名前をつける(クラス名・メソッド 名) • 契約プログラミング：型を使って事前条件(引数の型）と事後条件（返す型）を表明 2022/8/3 15
16. クラス設計：複雑さを分離する ビジネスルールクラスの設計（ドメイン層） ✓ 事業活動の決め事（ビジネスルール）を ✓ 値の種類／区分定義に注目して ✓ 宣言的に記述 ビジネスアクションクラスの設計(アプリケーション層） ✓ 計算判断の実行（ドメインオブジェクトを使った計算判断の実行） ✓ 記録・参照の実行 ✓ 通知・依頼の実行 2022/8/3 16
17. ドメインモデル方式で アプリケーション全体を どう組み立てるか？ 2022/8/3 17
18. ビジネスルールクラス 事業活動の決め事 計算判断ロジックの 宣言的な記述 POJO 複雑 ドメインモデル 2022/8/3 18 Java/Spring Bootの実装例
19. ビジネスアクションクラス 計算判断の実行 通知・依頼 記録・参照 @Service ビジネスルールクラス 事業活動の決め事 計算判断ロジックの 宣言的な記述 POJO 単純 複雑 ドメインモデル 2022/8/3 19 Java/Spring Bootの実装例 使う
20. 永続化クライアント @Repository JDBC Template SQLMapper 通信クライアント @Component Rest Template JMS Template アクションの起動 @Controller @RestController @MessageListener @Scheduled ビジネスアクションクラス 計算判断の実行 通知・依頼 記録・参照 @Service ビジネスルールクラス 事業活動の決め事 計算判断ロジックの 宣言的な記述 POJO 単純 複雑 フレームワークで単純化 フレームワークで単純化 ドメインモデル 2022/8/3 20 Java/Spring Bootの実装例 使う
21. クラス設計を改善する（リファクタリング） 分割不足（大きなクラス＝低凝集）を改善する ✓メソッドの抽出（と名前づけ）→関心事の分離の地ならし ✓クラスの抽出（と名前づけ） ✓クラス数が増えるのでパッケージの追加/サブパッケージの追加（と名前づけ） 分割意図を説明する ✓パッケージ名を工夫する ✓クラス名を工夫する 分割した要素（クラス・パッケージ）の凝集度をさらに改善する ✓クラスの移動 ✓メソッドの移動 ✓インスタンス変数の移動 ✓パッケージ/サブパッケージの移動（パッケージ構造の組み替え） 2022/8/3 21
22. テーブル設計のスタイル 2022/8/3 22 ソフトウェアの変更を楽で安全にするための
23. テーブル設計の分かれ道 ミュータブル（変更可能）なデータモデルでテーブル設計 • レコードの上書き更新可能 (SELECT FOR UPDTE …; UPDATE … ; COMMIT ;) • NULL 許容（後でUPDATEするカラム) • 削除フラグ（UPDATE) • 更新プログラムID・更新タイムスタンプ イミュータブル（変更不可）なデータモデルでテーブル設計 • 事実の記録を徹底 INSERT only • 予定した・変更した・完了した、これらも「事実の発生」として記録 • 事実の記録だけあれば（原理的には）状態は導出可能 • キャッシュやビューとして状態テーブルを追加することはある 2022/8/3 23
24. イミュータブルデータモデルを選ぶ • 事実の記録を徹底する • 事実を消さない（上書き変更しない） • 事実の記録があれば状態は動的に導出できる • 上書き更新（UPDATE）は、データ操作が複雑になり、状態判 定ロジックなどSQL/プログラムが複雑になる 2022/8/3 24
25. イミュータブルデータモデルの効果 挙動が安定する • 同じ条件で参照すれば、必ず同じデータを取得できる • 書込みが単純になる（INSERT ONLY) • 読み取りも単純になる（必要な事実だけ取得、WHERE句の単純化） ドメインモデル方式と相性がよい • ビジネスルールは、発生した事実を使った計算判断 • 同じ事実からは必ず同じ結果になるのがビジネスルール 分散システムと相性がよい • 同じ事実（不変なデータ）をあちこちで複製しても不整合は起きない • 上書き更新イベントを分散システムに正確に伝播するのは難しい 2022/8/3 25
26. イミュータブルに設計したテーブル データベース制約の徹底 • 外部キー制約 • 一意制約 • NOT NULL 制約 テーブルのカラム数が減る • ひとつのテーブルには発生時点が同じカラムだけ • 必須の情報だけ（任意項目は別テーブル） • 状態を上書き記録するカラムがなくなる • 更新プログラムIDと更新タイムスタンプがなくなる 2022/8/3 26
27. プログラムが単純かつ明快になる SQLが単純になる • カラム数が少ない • NOT NULLが保証されている • 用途別・状態別にテーブルが分かれている データベース操作プログラムが単純になる • ドメインオブジェクトと事実を記録したテーブルのマッピングが単純になる テーブル更新(状態変化）を前提にした複雑な記述がなくなる • 状態による WHERE 句、CASE式、if 文/switch文が激減する 2022/8/3 27
28. 開発のやり方 2022/8/3 28 ソフトウェアの変更を楽で安全にするための
29. 開発のやり方の分かれ道 目標の固定から出発する分解思考の開発のやり方 • 固定のゴールを目指してタスク分解・工程分割・分業体制を固定する • 詳細で具体的な問題は、実際に作る後半の工程にしわ寄せ • 後工程になるほど予実差異の検出を詳細で具体的にやる（前工程はゆるい） 目標の仮決めから出発する組み立て思考の開発のやり方 • とっとと作りはじめて、とっとと成長させる • 実際に動くコードで事実を積み上げ認識を合わせながら進める • 仮決めの目標との差異を検出しながら、目標を調整 & 進め方を調整 2022/8/3 29
30. 組み立て思考の開発のやり方 目標は可変 • 構想（長い目で見た理想的な姿）を思い描く（方向性の認識合わせ） • 構想は（作ってみて）知見が増えれば変化する • 構想は状況の見通しが変われば変化する 構想（目標）の変化を前提にソフトウェアを作る • 変更しやすい構造を選択する • ソフトウェアを変える環境を整備する(プロセス/開発環境/運用環境) • ソフトウェアを変え続ける開発のやり方に習熟する 2022/8/3 30
31. 変化しやすい構造を選択する 構造の分かれ道 • ツリー構造（トップダウン） • ピラミッド構造（ボトムアップ） • ネットワーク構造 変更が楽で安全なネットワーク構造 • ツリー構造やピラミッド構造は部分の差し替えがやっかいで危険 • ネットワーク構造は部分の差し替え・追加・切り離しが楽で安全 2022/8/3 31
32. とっとと作る とっとと作る準備 • IDE(統合開発環境）・リポジトリ・CI/CD・実行環境の整備と習熟 • 基本構造と要素技術の選択と習熟 • 設計スタイルの選択と習熟 コードファースト • ラフスケッチ・箇条書き程度の情報からコードを書いて動かしてみる • 課題を発見し、事実に基づいて対応アクションを起こす 自己文書化・設計の可視化 • プログラムを仕様書・設計書として書く（動くだけなら不要な内容の丁寧に記述する） • コードから関連図や一覧表を自動生成 • コンパイラやインスペクションツールで文書品質を保証 2022/8/3 32
33. 設計スキルを身につける 2022/8/3 33 ソフトウェアの変更を楽で安全にするための
34. 設計スキル 設計スキルの実体 • 経験則の脳内データベース • 超高速の脳内検索 • 目の前の課題と経験則との高度なマッチング（文脈の違いの吸収） 設計のスキルアップの方策 • データベースを拡充する（経験則を増やす） • 検索速度をあげる（脳内キャッシュ、脳内パーティショニング） • パターンマッチ能力をあげる（文脈差異に適応） 2022/8/3 34
35. 設計スキルアップの行動計画 経験則を増やす • 実際に作ってみる（設計スタイル、要素技術、構造、ツール、…） • 他人の経験則を知識として学ぶ • 他人の経験則・目の前の課題・体験知から新たな経験則を導き出す 脳内キャッシュの最適化 • 使わないと期限切れでキャッシュから消える⇒適時リフレッシュする • リフレッシュを繰り返した内容は長期記憶に書き込まれる • さらに繰り返すと小脳にキャッシュされる（体が覚える） 2022/8/3 35
36. 設計スキルアップの行動計画(続き） 脳内の経験則データベースのパーティショニングを調整する • 整理の軸・枠組みのバリエーションを絵にしてみる • 体系だった説明の書籍の構造を鑑賞する • 脳内データベースの構造（参照経路）が変わる 経験則と目の前の課題のマッチング精度を上げる • 微妙なパターンアンマッチから学ぶ（「なにか変」違和感センサー） • 他のパターンに変えてみて結果を評価（マッチ度の学習） • 文脈（目的・状況・判断基準）に依存したマッチングを工夫する 2022/8/3 36
37. まとめ 2022/8/3 37
38. 良い設計は悪い設計より 変更が楽で安全である 2022/8/3 38
39. ソフトウェアの変更が楽で安全であれば • 事業活動の変化のスピードを上げられる • 事業活動の変化のコストを下げられる • 開発者の学びと成長をソフトウェアに反映できる • 開発者の成長の機会を増やせる • 費用対効果の高い技術に移行できる 2022/8/3 39
40. 変更を楽で安全にする設計 それが開発者がやるべき仕事 私が実践している設計の考え方とやり方は、この価値観に基づいている 2022/8/3 40
41. 2022/8/3 41 補足資料 どうやっているか クラス設計の基本パターン 設計のためのモデリング 複雑さとの戦い方
42. どうやっているか ・クラス設計 ・テーブル設計 ・自己文書化 2022/8/3 42 図書館の蔵書貸出アプリケーション https://github.com/system-sekkei/library
43. ドメイン層のクラス設計 2022/8/3 43 JIGでソースコードから自動生成
44. ソースコードから実装の中核を可視化 application/service/* domain/model/* 2022/8/3 44 JIGでソースコードから自動生成
45. 入出力構造の可視化 プレゼンテーション層 presentation/* アプリケーション層 application/* データソース層 datasource/* 2022/8/3 45 JIGでソースコードから自動生成
46. テーブル設計 2022/8/3 46 JIG-ERDで自動生成 スキーマ構造 外部キー参照関係
47. 2022/8/3 47 JIGでソースコードから自動生成 ドメインモデル（ユビキタス言語）
48. 2022/8/3 48 JIGでソースコードから自動生成 ビジネスアクション（ユースケース）
49. クラス設計の基本パターン 2022/8/3 49
50. 値の種類で分割 対象領域の事実を扱う基本クラス 基本的な値を 扱うクラス 数量 金額、単価、個数、人数、百分率、千分率 日付・時刻 日付、日数、時刻、時間 区分を表す値を 扱うクラス 種類の違い 商品種別、会員種類、料金区分、配送方法 状態の違い 処理待・処理中・処理済、在庫有無、予約可否 範囲を 扱うクラス 数量の範囲 価格帯（x円～y円)、数量範囲(x個～y個) 日付・時間の範囲 期間（開始日～終了日）、時間帯（開始時刻～終了時刻） 対象領域で扱うこれらの値の種類ごとに、ビジネスルール（計算判断のロジック）と 事実の表現（インスタンス変数）をクラスで定義する 区分を整理し ロジックを集める プリミティブな 計算式を隠蔽 判断ロジックの カプセル化 2022/8/3 50
51. クラスの設計：メソッドの集合として定義 四則演算 足し算、引き算 add(), plus(), subtract(), minus() 掛け算 multiply(), times() 割り算、あまり divide(), remainder() 比較演算 等値 equalsTo(), notEqualsTo() 大小、前後 greaterThan(), lessThan() , isAfter(), isBefore() 境界 境界要素の取得 MAX, MIN 順序 前の値・次の値 previous(), next() 文字列形式 文字列に変換 toString(), show(), format() 文字列から変換 from(), parse() ✓ 対象領域で関心のあるメソッドだけに絞り込むことで、クラスの意図（型の意味）が明確になる ✓ 引数の型やメソッドの返す型を目的特化・用途限定にするほど挙動が安定する（契約による設計） （汎用的なライブラリクラスと設計の方向が逆） 事前条件・事後条件 事実を扱う計算判断ロジックの候補 2022/8/3 51
52. 組み立て役のクラスの形 分割したクラスの組み合わせ方 日時 日付 時刻 明細行 単価 数量 料金計算コンテキスト 価格体系 割引 適用日 税率 税区分 顧客種別 注文番号 計算判断の文脈を 特定する番号 永続化された事実を 集めて、コンテキスト を組み立てるためのキー 2022/8/3 52
53. 組み立て役のクラスの形 コレクション操作をカプセル化 コレクションとその操作をカプセル化して独自のクラスを作る 操作の意図を公開し、操作の実装は隠蔽する リスト操作をカプセル化 filter操作 サブリストの抽出 map操作 別の要素のコレクションに写像 reduce操作 合計、個数、最大、最小、… セット(集合)操作をカプセル化 部分集合(subset) 和集合(union) 差集合(minus) 共通集合(intersect) マップ(写像)操作をカプセル化 マップのマップから値の取り出し 逆写像（値からキーの特定） 写像の併合(merge) 共通写像(intersect) 表形式の計算ルールや判定ルール スキルセット ルールセット 商品一覧 メンバー一覧 注文一覧 … 2022/8/3 53
54. 組み立て役のクラス：ビジネスアクション アプリケーション層のクラスの分割と組み立ての形 請求書発行 サービス 決済 サービス 請求アクティビティクラス 出荷アクティビティクラス 出荷指示 サービス 売上計上 サービス 出荷通知 サービス 注文処理シナリオクラス 通知・記録・参照の 基本アクションを表現 関心事ごとの 活動体系を表現 業務全体の 流れの表現 ここにごちゃごちゃ書かない 計算判断はビジネスルールクラスを利用する（ロジックをここに書かない） 分ける 分ける 分ける 2022/8/3 54
55. 設計のためのモデリング 2022/8/3 55 事業活動を理解して設計するためのモデリングの基礎知識 機能一覧やユースケース一覧は クラス設計のためのモデリングではない
56. 取引先 顧客 商品 サービス 在庫 部門 部門 業務 業務 ビジネスユースケース (業務バリエーション） 業務フロー ビジネスルールの言語化 システム境界 （インタフェース） ユースケース 画面 外部接続 情報モデル 状態遷移 ドメインモデルの設計と実装 事実の記録(不変) 状態の表現(可変) データベースの設計と実装 業務機能クラス データ操作クラス 画面制御クラス API制御クラス 収益構造 事業方針 アプリケーションの設計と実装 要件のモデル(RDRA) 事業活動の 仕組と決め事 クラスで表現 区分 計算式 条件 判定表 分類 提示 予定 実行 申込 手配 約束 金額 数量 区分 範囲 集合 判定表 文脈 方針 日付 一覧 履歴 契約 計画 約束 結果 事業活動のモデル(ビジネスコンテキスト)
57. 事業活動を大局的に理解する（whyの理解） • 事業活動は顧客との契約（受注）とその履行である • 事業活動は協力企業との契約（発注）とその履行である • 事業活動は競合との差別化行動である • 事業活動を発展させるために金銭的利益が必要 • 事業活動を発展させるために顧客の成功が必要 • 事業活動を発展させるために仕事のやり方の改善が必要 • 事業活動を発展させるために個人と組織の学習と成長が必要 2022/8/3 57
58. 事業活動を時系列で整理する • 事業活動を業務イベントの連鎖として捉える • 受注系：商流イベント・金流イベント・物流イベント • 発注系：商流イベント・金流イベント・物流イベント • 事業活動には表舞台と舞台裏の二つの領域がある • 顧客が認知する表舞台の業務イベント • 顧客が関知しない舞台裏の業務イベント 2022/8/3 58
59. ビジネスルールの発見とクラス設計 • 業務イベントには必ず業務上の決め事がある • 事前条件：業務イベントが発生してよい条件 • 事後条件：業務イベントが発生した時の約束事 • 業務上の決め事はビジネスで一般的なパターンがある • その決め事を表現するクラス設計も基本的なパターンがある • それらの基本パターンを出発点にして、その事業の独自性・差 別化の中核となる業務（コアドメイン）に焦点を合わせて、ク ラス設計に反映する 2022/8/3 59
60. 一般的な業務の関心事とクラスの候補 価値の提供能力 在庫(inventory) 提供能力(capacity) 提供可能性(availability) 手配(arrangement) 購入(purchase) 調達(procurement) 提供する価値の表現 物品(goods, product) 役務(service) 権利(right) 利用(usage) 移動(transport) 価格(pricing) 提供条件(policy, conditions) 販売機会 商品カタログ(catalogue) 引合(inquiry) 見積(estimate) 提示(offer) 約束と履行 契約(contract, order) 予約(reservation, booking) 値引(discount) 引渡(delivery) 請求支払(billing, payment) 進捗(progress, milestone) キャンセル(cancel) 関係 顧客(customer, account) 関係(relationship) 連絡(contact) 伝達(communication) 通知(notification) 計画と実行 予定(schedule) 計画(plan) 行動(action) 進捗(progress, milestone) 2022/8/3 60
61. 事業活動とテーブル設計 • 業務イベント（事実の発生）を記録する • 事実の記録は不変（イミュータブル:insert only） • 変更・キャンセルなども事実の発生として記録 • 状態は、事実の履歴があれば動的に導出できる • 動的な状態の導出が性能面で実用に耐えない時は、キャッシュとして状態テーブル を利用することはある 2022/8/3 61
62. 複雑さとの戦い方 2022/8/3 62
63. 複雑さとの戦い方（１） • 複雑さの主因は、金額・数量・日付の計算判断 • アプリケーションで扱う値を特定する • 独自の型として定義（値オブジェクト） • 値オブジェクトに計算ロジックをカプセル化する • 実装の詳細の隠蔽 • 変更の影響の局所化 • ビジネスルールを記述する基本語彙を独自の型で表現 • int型/String型でビジネスルールを記述しない 2022/8/3 63
64. 複雑さとの戦い方（２） • 複雑さの主因は条件分岐 • 分岐する条件の特定と整理 • 商品区分、顧客区分、物流区分、… • 提供能力（引当、手配）の状態区分（例：引当可、引当済、…） • 契約履行の進行状態（例：出荷待ち・出荷指示中・出荷済） • 条件分岐の組合せを特定し整理するクラス設計 • 区分オブジェクトの定義とリファクタリング • 条件分岐（if文/switch文）の記述とリファクタリング • (List)のフィルタリングと集約演算 • 集合(Set)の演算 • 写像(Map)による構造化 2022/8/3 64