19
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ドメイン駆動設計 - 実践企業が語るBefore/After - に参加して

Last updated at Posted at 2025-01-21

Findy Tools開催のオンラインイベントドメイン駆動設計 - 実践企業が語るBefore/After -に参加してきました。
ドメイン駆動設計(以下DDD)についてLINEヤフーの山口氏、塩川氏とパーソルキャリアの池田氏が講演されました。
この記事では、講演内容のまとめと所感を交えてお届けします。

なぜDDDを採用したのか

LINEヤフー

コミュニケーションコストの増加とシステムの複雑化に対応するため。

コミュニケーション

  • 言葉の違いから認識の違いが発生している
  • マーケと技術で言葉の変換が必要

システム

  • 1クラスにすべての処理が書いてある
  • 処理のシーケンスが複雑で見通しが悪い
  • 仕様の複雑性<システムの複雑性となっている

パーソルキャリア

技術的負債や不明確な仕様を解消するため。

  • 機能拡充やユーザー増加に対して、小手先のリファクタリングでは対応ができなくなってきた
  • 保守性の低いコード・不明確な仕様・分散モノリスが課題

両社はそれぞれ異なる背景からDDDを採用しましたが、共通して目指したことは、システムの複雑さを解消し、開発スピードと保守性を向上させることでした

どのようにDDDを実践したのか

事業領域の分析とコンテキスト分割

両社とも業務領域を分析し、複雑なシステムを扱いやすいようにするためコンテキストを分割しました。
LINEヤフーでは割引クーポンが複雑性を増していましたが、計算のコンテキストと適用のコンテキストに分割することに分けて管理しました。
パーソルキャリアではモノリスを解消することもDDDの目的として挙げており、コンテキストマップを活用してマイクロサービスの境界を定めました。

ユビキタス言語の作成

業務で使用される用語をそのままコードに反映させるユビキタス言語を使用することで、開発者と業務担当者の認識のずれを軽減しました。

ドメインモデリング

分析モデルと対応するドメインクラスを作成し、ドメインクラスにロジックを寄せることで凝集度を高めることを意識されていました。
最初はドメインエンティティ的なものがありはしましたが、ロジックがないデータクラスとなっており、サービスクラスに業務ロジックが集中していました。
それをロジックを細かく分割しドメインクラスに実装、実装できなかったドメインロジックはドメインサービスへ一旦実装し、後で俯瞰してドメインクラスへ移行する、これを繰り返すことであるべき姿を目指しました。

LINEヤフーでは山口氏がドメインエキスパートとしてプロジェクトに参加していのに対し、パーソルキャリアでは仕様が明確になっておらず、ドメインモデリングに苦労していたのが印象的でした。
パーソルキャリアではドメインモデリングに際し、信頼できる情報源がないため、ドメインエキスパートだけでなく、アプリケーションの実動作や陳腐化したドキュメント、ソースコード解析など複数の情報源からモデリングを行い精度を向上させました。

アーキテクチャ

LINEヤフーではドメイン中心型のレイヤードアーキテクチャを採用していました。
下記の記事の「DDD (domain driven design) とは」に記載されているアーキテクチャと同じで、純粋なレイヤードアーキテクチャに対して依存性の逆転を適用してインフラ層を逆転させたものになります。

パーソルキャリアではマイクロサービスであることに意識をしており、GraphQLを採用することで、マイクロサービスの統合を自然な形でできるようにしました。

その他

両社ともペアプログラミングでモデラーの育成や、若手エンジニアに知識の共有を行っていました。
特にパーソルキャリアではモデラーの育成を最重要テーマとして取り組んでいるそうです。

DDD導入による効果

  • 開発スピードの向上
    DDDの導入により、システムの複雑さを軽減し、開発スピードが向上
  • 可読性の向上
    ソースコードと業務知識が一体化し、コードの可読性が向上
  • チームの共通認識
    チームの誰もがコア部分の改修に取り組めるようになり、開発メンバーがどこに手を入れればよいかの共通認識が持てるように
  • 新メンバーの戦力化
    効率の良いキャッチアップが可能になり、新しくチームに加わったメンバーが早く戦力になれるように
  • 事故発生率の改善
    バグが減少し、事故発生率が改善
  • 仕様の複雑性への対応
    システムの複雑性=仕様の複雑性を維持
  • テストの容易性
    責務が小さくなったことで、単体テストの実装が容易に

おわりに

今回のイベントを通じて、ドメイン駆動設計がどのように現場で導入され、具体的な効果をもたらしたのかを深く理解することができました。
DDDを導入するには、業務の深い理解と組織全体での取り組みが不可欠です。しかし、それにより得られる成果は、開発者としての視点だけでなく、事業成長にも大きな貢献をもたらすものでした。
この学びを自分自身のプロジェクトに活かしていきたいと思います

19
9
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
19
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?