😽
ドメイン駆動設計を導入するためにやったこと
概要
2022/01/17に開催された下記勉強会のメモです
セッション
①ドメイン駆動設計のプラクティスでカバーできること、できないこと
DDDの目的
- ソフトウェアの機能性を高める -> 役に立つものを作る（作ったけど使えないを避ける）
- ソフトウェアの保守性を高める -> 長期間開発しても機能拡張が容易（開発速度が低下しない）
アプローチ
- ドメインエキスパートと共に行うドメインモデリング
- 頻繁なモデルの変更に耐えられる実装パターン
DDDはドメインが複雑な場合に向いている -> 理解するのが難しかったら複雑
実際のアプローチとしてはこちらの過去記事を参照とのこと
すんなり行ったこと
- モデル図作成
- モデル図を元にしたコーディング
- コーディング標準の普及
- お手本実装があると横展開しやすい
- 「規約」でなく「標準」（意図的に分ける）
- テスト実装
- テストがあると楽、を感じでもらう
- ないと考えられないぐらいまでには浸透
苦戦したこと、していること
- 「何を作るか」から「どうすれば活用してもらえるか」への踏み込み
- お客様の声を反映するためのアクションに踏み出す必要性
- お客様の解像度をあげる
- プロダクトマネージャー、カスタマーサクセスと連携、ヒアリングと仮説検証を繰り返す
- EA(アーリー)とGA(一般)で分けて新機能リリースなど
- サイクルの仕組み化
- プロダクトマネージャー、カスタマーサクセスと連携、ヒアリングと仮説検証を繰り返す
モデリングの参考動画
執筆書籍
②巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例
DDDの導入理由
- コアドメインを見定め、開発費用対効果を高めるため
- 巨大レガシーシステムの技術的負債解消
コアドメインはDDDの真の主人公
ドメインエキスパートへインタビュー、問題領域と解決領域を整理
- どの事業領域へ投資するか
- モノリシックシステムは複数の問題領域にまたがりがち
- システム分離の検討
- 手作業のシステム化
- 有識者わからないあるある
エンジニア全体の納得感醸成が必要
- DDDベースでリファクタしてもエンジニア全体に意図が理解されていないと混乱を招く
課題と導入技術が合致していることが重要
- きちんと説明できるように
「人生のコアドメイン」というSlackスタンプが爆誕した話なんかいい
DDDとRails-wayは相性が悪い
こちらの本を参考テキストにプロダクションコードを使って勉強会を実施（SpatialChatを利用）
ミノ駆動さんといえばこれ
バグハンター2 REBOOT
今春の設計技術書も期待
③変更を楽で安全にする良い設計を目指して
NRIでの実証実験の結果はこちら
Discussion