■ 目次
こんにちは 配配メール開発課所属 Jazumaです。
1/17 (月)にオンラインでドメイン駆動設計導入事例の勉強会がオンラインで開催されました。
modeling-how-to-learn.connpass.com
平日の夜にも関わらず500人以上の方が参加しており、設計に関心を持っているエンジニアが多いことを実感しました。
今回の勉強会では以下3名の方がが登壇されました。
- 松岡@ログラス/DDD,アジャイル (@little_hand_s) | Twitterさん
- ミノ駆動 (@MinoDriven) | Twitter さん
- 増田 亨． (@masuda220) | Twitter さん
ドメイン駆動設計というとそのメリットや成功例が取り上げられがちですが、今回はドメイン駆動設計で苦労したことや解決できなかったことも紹介されました。
ドメイン駆動設計のプラクティスでカバーできること、できないこと
松岡幸一郎さんの発表です。DDDの導入にあたって上手くいったこと/ いかなかったことが紹介されました。
前提知識： DDDの目的
ソフトウェアの機能性を高める ⇒ 機能性 = 顧客の役に立つこと
ソフトウェアの保守性を高める ⇒ 保守性 = 長期間にわたり機能拡張が容易であること。
DDDの目的： 顧客の役に立つソフトウェアを頻繁な更新に耐えられるものにする
スムーズに進んだこと
- 松岡さん主導のモデリング
- モデル図をもとにしたコーディング
- 新規開発時、モデル図を見ながら開発ができたので役に立った
- コーディング標準普及
- 標準的なコード手本があると実装の横展開がしやすかった
- 規約ではなく「こんな風にするとやりやすい」、というようなお手本的なもの
- テスト実装
- テストのメリットを実感してもらうと浸透しやすかった
テストコードの量が増えた時、「モデリングしたいので一緒にモブ作業してくれませんか？」と言われたときに変化を実感できたようです。
苦戦したこと・していること
- 「何を作るか」から「どうすれば活用してもらえるか」への踏み込み
- 作ったものをより顧客の役に立つものにすることが難しい
- お客様の解像度を上げる
- PMやCSと協力してヒアリングと仮説検証を繰り返す
DDDを導入した後、プロダクトの機能性を高めることに苦労したと仰っていました。
プロダクトを活用していただくための取り組み
新機能を先行体験する顧客を選定してPdMがヒアリング、フィードバックを受ける
既存機能についてお客様の声を聴く機会を設ける。そこからスプリントの案件として計上する
まとめ
- DDDは保守性・機能性改善に効果が大きい
- 社内の人間だけでは機能性を上げきれない
- とにかくお客様の声を聴いて業務を理解することが重要
巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例
ミノ駆動さんによる発表です。DDDを用いてレガシーシステムの品質向上に取り組んだというお話です。
DDDの導入理由① コアドメインを定めて開発の費用対効果を高めるため
- 限られた開発リソースを有効に利用するためにシステムのコアドメインが何なのか見定める必要があった
- 「問題領域」(実現したいこと)と「解決領域」(実現手段)と整理することから始めた
※ コアドメイン： システムの競争優位性を発揮し、最も付加価値を高めるべき領域
取り組んだこと
例： 解決したい問題等...
⇒ 事業領域を明確化し、コアドメインを特定できた
苦戦したこと
DDDの導入理由② レガシーシステムの技術的負債解消
- 巨大なRailsアプリの負債で変更容易性が落ちる
- 負債を産みにくいような設計にしたい
という目的のもと設計改善が行われました。 しかし、開発組織全体に意図や目的が共有されていなければ混乱を招くという懸念があり 実際に最初のうちは他のメンバーがRailsの手法に乗っ取って開発して負債が解消されませんでした。
苦戦したこと
- 現場の課題とDDDという技術をどう結び付けて説明するか
- DDD: コアドメインの価値を高めて長期的に成長させるための設計思想
- 現場の課題：ActiveRecordをRepositoryに隔離してドメインの知識を独立させる
- 結果： 技術負債に困っているメンバーが多かったので「FatModelを意味の違う概念単位で分割する」という考えに賛成するメンバーは多く、技術負債は次第に低減
苦労していること
- 設計がRailsの仕様に引っ張られて品質が落ちる
- ActiveRecordを中心に機能が集約されているため、Railsの実装に設計が引っ張られる
- Rubyという言語の特性
- 型のサポートがないので依存関係を正確に追跡できない。
- リファクタリング効率がどうしても落ちる。
基幹システムの変更を楽で安全にする
増田亨さんによる発表です。松岡さんとミノ駆動さんは比較的若い会社でのケースでしたが、 増田さんは伝統的な大手企業におけるDDDの実践例について発表されました。
参画していた案件
- 損保会社のシステム
- 巨大ECサイトの基幹システム
参画案件のテーマ
- ビジネスの要求にこたえるシステム変更スピード
- ソフトウェア開発コストの削減
- 修正コストの削減
現場でやっていること
whyの合意形成
howについての認識合わせ
- ビジネスルール(計算判断ロジック)中心の設計
- 事実の記録中心のテーブル設計
- 一覧網羅ではなく濃淡づけとカテゴライズ(要点を見定める)
結果
DDDの導入によりシステム仕様の管理が膨大なExcelシートから業務マニュアル + ソースコードに変化しました。 また、ビジネスロジックがドメインオブジェクトに集約されたことで機能改修に伴うコードの変更量が減少しました。
感想
DDDを頭ごなしに導入するのではなく、小規模なところから始めてチームのメンバーにメリットを実感してもらうのが大切だと思いました。
DDDはソフトウェアの価値を高める手段であり、最も重要なのはシステムのコアドメインを関係者とのやりとりから見定めることだということが実際の導入事例を通して理解できました。
エンジニアだからと言ってシステムが扱う事業に無関心ではいられないと再認識しました。
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
rakus.hubspotpagebuilder.comイベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！
rakus.connpass.com
