😽

ドメイン駆動設計を導入するためにやったこと

2022/01/26に公開約1,900字

概要

2022/01/17に開催された下記勉強会のメモです

https://modeling-how-to-learn.connpass.com/event/229811/

https://togetter.com/li/1832193

セッション

①ドメイン駆動設計のプラクティスでカバーできること、できないこと

DDDの目的

  • ソフトウェアの機能性を高める -> 役に立つものを作る(作ったけど使えないを避ける)
  • ソフトウェアの保守性を高める -> 長期間開発しても機能拡張が容易(開発速度が低下しない)

アプローチ

  • ドメインエキスパートと共に行うドメインモデリング
  • 頻繁なモデルの変更に耐えられる実装パターン

DDDはドメインが複雑な場合に向いている -> 理解するのが難しかったら複雑

実際のアプローチとしてはこちらの過去記事を参照とのこと

https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month

すんなり行ったこと

  • モデル図作成
  • モデル図を元にしたコーディング
  • コーディング標準の普及
    • お手本実装があると横展開しやすい
    • 「規約」でなく「標準」(意図的に分ける)
  • テスト実装
    • テストがあると楽、を感じでもらう
    • ないと考えられないぐらいまでには浸透

苦戦したこと、していること

  • 「何を作るか」から「どうすれば活用してもらえるか」への踏み込み
    • お客様の声を反映するためのアクションに踏み出す必要性
  • お客様の解像度をあげる
    • プロダクトマネージャー、カスタマーサクセスと連携、ヒアリングと仮説検証を繰り返す
      • EA(アーリー)とGA(一般)で分けて新機能リリースなど
    • サイクルの仕組み化

モデリングの参考動画

https://www.youtube.com/watch?v=A2EU0paEVJ0

執筆書籍

https://booth.pm/ja/items/1835632
https://booth.pm/ja/items/3363104

②巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例

DDDの導入理由

  • コアドメインを見定め、開発費用対効果を高めるため
  • 巨大レガシーシステムの技術的負債解消

コアドメインはDDDの真の主人公
ドメインエキスパートへインタビュー、問題領域と解決領域を整理

  • どの事業領域へ投資するか
  • モノリシックシステムは複数の問題領域にまたがりがち
    • システム分離の検討
  • 手作業のシステム化
  • 有識者わからないあるある

エンジニア全体の納得感醸成が必要

  • DDDベースでリファクタしてもエンジニア全体に意図が理解されていないと混乱を招く

課題と導入技術が合致していることが重要

  • きちんと説明できるように

「人生のコアドメイン」というSlackスタンプが爆誕した話なんかいい

DDDとRails-wayは相性が悪い

こちらの本を参考テキストにプロダクションコードを使って勉強会を実施(SpatialChatを利用)

https://www.amazon.co.jp/dp/B073GSDBGT
https://spatial.chat

ミノ駆動さんといえばこれ

https://twitter.com/MinoDriven/status/1380773721032433674
https://speakerdeck.com/minodriven/kusokododong-hua-userkurasu-dekao-eruji-shu-de-fu-zhai-jie-xiao-falseguan-dian?slide=50

バグハンター2 REBOOT

https://game.nicovideo.jp/atsumaru/games/gm22047

今春の設計技術書も期待

③変更を楽で安全にする良い設計を目指して

NRIでの実証実験の結果はこちら

https://www.nri.com/jp/knowledge/publication/cc/chitekishisan/lst/2020/09/10

Discussion

ログインするとコメントできます