スタートアップでDomain-Driven Design(DDD)を始めた時の困難

スタートアップでDDDを始めた時の困難

所属
株式会社TechBowl
住んでるところ
東京
何やってる？
「TechTrain」というサービスで反復横跳びし続けている
何でも屋さん(Laravel, Next.js, AWS, etc...)
趣味
お酒(よく溺れる)
サウナ
読書
2024-05-13 | スタートアップでDDDを始めた時の困難 3

TechTrain
エンジニア教育+Directスカウトのサービス。
Coding Stoicをテーマにちゃんとコードを書いていこう
ね！というメンターが多めのエンジニアを育てるための
サービスです。

一緒に働いてくれる人を探しています！
1. バックエンドエンジニア(Laravel + DDD)
2. フロントエンドエンジニア(Next.js with TypeScript)
3. TechTrainのメンター-> 筋がいい人なら教えたいぜ！

結論

チームの状態に合わせてグラデーションをつける

前提
職種を超えて、信頼を獲得していること、しようとしていること
ドメインエキスパートが増えるように施策は打っておくこと
業務委託を含めたチームが急激に増え始めたタイミングであること

なぜ戦略的DDDの導入だったのか？

ドメインが広くなった・・・

ドメイン知識を全く知らない人の入社が増えた
人材業界、ダイレクトリクルーティング、エンジニアについて知らないぞ？
飲み屋出身だから本当に何も知らないぞ？

で、ここからちゃんと「チームの状態に合わせてグラ
デーション」は何をやったのか？

全体のMaxプランのアクション
エンジニアサイドビジネスサイド関わりなく
1. 全員がドメインの知識を習熟し、顧客が誰かを定義している
2. 用語の揺れなどがあれば、用語集などに編集に行く
3. ユースケースなどの定義に全員が参加して進める

まぁ工数的に難しいことが多い

グラデーションをつけて導入していく

戦略的設計の主要な要素
△ドメインモデリングとドメインの識別
境界づけられたコンテキストの設定
コンテキスト間の関係の管理
システムの分割・統合(コンテキストのとも言えるかも)

ドメインモデリングとドメインの識別
Maxプラン
次のことを関係者全員で行う
コアドメイン、サブドメインの特定
ドメインモデル図の作成

ドメインモデリングとドメインの識別
グラデーション
ドメインモデル図などに揺れや漏れがある時にエンジニアが収束させにいく
最低限のビジネスサイドとエンジニアでドメインモデル図の作成
ステークホルダーへの確認と修正

どの時点で見直す？
システムも含めて分割を行い、関係者の分割をできたら見直しを入れる

境界づけられたコンテキストの設定/コンテキスト間の
関係の管理
Maxプラン

関係の管理
最低限のエンジニアとビジネスサイドで定義して勝手にやれるうちは、あまり明確に
ドメインエキスパートが抑えこみに行かない

関係の管理
いつ見直すのか？
勝手にチームでこれができなくなってきた時にドメインエキスパートがここを厳しめ
にちゃんとやるひつようが出てくると理解

システムの分割・結合
Maxプラン
Microサービスなどにして分割していく

ユースケースをどのドメイン領域で誰が何をやっているのか？などを明確に分け
て進めている

いつ見直すのか？
分けないとアウトカムが明らかに出ないようになってきている状態、認知負荷を
確実に超えてきたなと言える状態になってきた

このグラデーションによるデメリット
チームのカルチャーによって、アウトカムではなくアウトプットへの執着になり
うる
エンジニアとビジネスサイドの確認、連携がうまく機能しない可能性がある

全体のグラデーションとしてのアクションのまとめ
1. 最低限の関係者が集まり、ドメインについての情報を集約と深掘り
2. 集約した情報をもとにユースケースを整理し、共有
3. ドメインモデル図など必要なドキュメントをエンジニアが起こす
4. 用語集は気づいたタイミングで職種関係なく更新
5. ドメインエキスパートがそれぞれドメイン知識を移植するための勉強会を開く

結論

以降は参考です！

1. DDDをどのように考えているのか

構成要素
ユビキタス言語
ドメインエキスパート
境界づけられたコンテキスト

ユビキタス言語
1. 業界についての情報
2. 実際の運用で利用する情報
3. 社内における独自の用語

ドメインエキスパート
1. 業界の事情を網羅している
2. ソフトウェアとドメイン知識を行使する現場との橋渡し

境界づけられたコンテキスト
同じ用語を別の使い方になっていないか？ということが重要
現場で揺れ始めているのを感じたら気づいたエンジニアから分割or統一に向かう

前提となるコンテキスト1: ドメインの領域が広いor複数ある
1. TechTrain(エンジニア教育のプラットフォーム)
2. DirecTrain(ダイレクトリクルーティング)
3. AgenTrain(人材紹介)
3つの業界をまたがっていると言っても良い。

前提となるコンテキスト2: チームのメンバー状態の急激な変化
1. 業務委託のエンジニア
2. 業務委託のビジネスサイド
3. 正社員のエンジニア
4. 正社員のビジネスサイド

2. なぜDDDを取り入れようと思ったのか
当時概念が多くなっていたにも関わらず何もまとめていなかった
事業の種類も増え、ビジネスサイドのエンジニアサイドの人数が増えていた
ビジネスサイドとエンジニアサイドで用語の分離が起こり始めていた

そこに現れてくれたDDDを実践している人の登場
最初のカジュアル面談のタイミングで概念の図を一緒に起こした
その時点で、これからも概念が大きく増えて横断的に利用される実感が湧いたた
め、DDDをチーム的に導入することに決めた
この時点で、戦術的実装についてはほとんど検討していなかった

概念をまとめるための細かいツールの変遷についてはこちらのブログを見ていただけ
ますと・・・！
DDD × Whimsicalで快適モデリングライフ！

3. 実際にどこまでワークしているのか、していないの
か

戦略的設計の主要な要素
️ドメインモデリングとドメインの識別
コンテキスト間の関係の管理
コンテキストの統合

なぜこれが必要か？
同じ言葉を使っているのに別の使われ方をしているということが出てきたら、こ
ちらを丁寧にやっていく必要があると思うが、今は必要ないと判断。
むしろ今やってしまうと、同じコンテキストで扱えているのに別で管理する必要
性に迫られ、必要のない工数が増える。
今は境界づけるようなものはほとんどない。一部あるが、チームで認識をとって
必要になった時にコンテキストを最低限分割することができている。
勝手にチームでこれができなくなってきた時にドメインエキスパートがここを厳
しめにちゃんとやるひつようが出てくると理解。

システムの分割・結合
これはやってない
というかエンジニアを採用できないとできない。
今ドメインの事情が諸々絡み合ってるので、システム自体の分割(特にバックエン
ド)が難しい。
ユースケースを変に統一しないことで割り切っている。
いろんなところで使われるからこそ、どこで誰かと言うところまで分けて定
義している
システムは分割していないが、その分アプリケーションレイヤーを細かく区
切って誰が何をするのかがわかりやすいようにしている。（戦術が少し入っ
てしまうんだけど）
サブドメインはやってない
ドメインがデカくなった時にしっかり分割を進めていけば、それが自然にサ
ブドメインになるんじゃね？
またサブドメインを跨ぐと、認知限界を超えてくると考えているので、一旦

結論

スタートアップでDomain-Driven Design(DDD)を始めた時の困難

Recommended

Recommended

More Related Content

Similar to スタートアップでDomain-Driven Design(DDD)を始めた時の困難

Similar to スタートアップでDomain-Driven Design(DDD)を始めた時の困難 (20)

スタートアップでDomain-Driven Design(DDD)を始めた時の困難