modeling-how-to-learn.connpass.com
前回に引き続き、こちらのイベントでお話を聞いてきました。自分用ノートです。
ドメイン駆動設計のプラクティスでカバーできること、できないこと
DDDの目的
ソフトウェアの機能性を高めること
- 役に立つものを作る、作ったけど使えないを避ける
ソフトウェアの保守性を高めること
- 機能拡張が容易でありつづけたい
アプローチ
-
- ドメイン知識の反映とフィードバック
保守性向上のためのアプローチ
目的が明確であれば、1, 2どちらかだけでも価値がある
DDDとの相性とは
DDDはドメインが複雑な領域に適用するのに向いている
実際のアプローチ
- https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month
- コードの作成
- レイヤーに跨るコーディング・テストの規約の整備
- ドメインモデル図を作成し、それを元に開発
- 地道なペアプロ・レビュー
- お客様の解像度をあげる
- PdM, カスタマーサクセスと連携、フィードバックのぐるぐる
- 新機能
- アーリーアクセス
- 既存機能
- CSから直接お客様の声を聞く機会を設ける
- [質問] EAとGAで、機能の出しわけするのは、feature flagのような仕組みを自作しているのでしょうか？？
- はい
すんなりいったこと
- モデル図の作成
- モデル図をもとにしたコーディング
- コーディング標準
- お手本実装があることで、横展開しやすかった
- テスト実装
- このレイヤーではこうしたらテストが書けるよね
- モデリング
- diagrams.net
- https://www.youtube.com/watch?v=A2EU0paEVJ0
巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例
問題領域と解決領域を考える
モノリシックシステムは複数の問題領域にまたがりがち - 在庫・配送・注文をモノリシックなECサイトが解決するなど
問題領域が不明な場合 - 何領域があって、システムがどう関わっているか - コアドメインを見定めるのは困難
取り組んだこと
- ドメインエキスパートにインタビューを実施
- 解決したい課題
- 目的
- ルール、どんな世界観か
- 登場概念と、考え方
→ これらの異なる境界が問題領域の境界
苦戦したこと
- 莫大な情報量
- 有識者が誰かわからない
- Rails Wayの引力
- Active Recordに機能が集中しているのでRepositoryパターンでActive Recordを隠蔽するのが大変
- Rubyの特性
- 動的型付け言語なのでリファクタリングが大変
基幹システムの変更を楽で安全にする
ミュータブルデータからイミュータブルデータへ
- 可能な限りUPDATEを使わない
- INSERT, DELETE
分解思考から組み立て思考へ
- 分解して人手をわけようから、全体像を見て組み立てていこう
現場で実践してみて
ドメインモデルパターンでは規定集・業務マニュアルが設計になる
