JJUG ナイトセミナー 「6.11 ドメイン駆動設計特集！ 」に参加しました。そのメモと感想。
コードに語らせるために by 和智 右桂氏
業務を理解してモデリング・実装するのは挑戦的でエキサイティングだ。
DDDとは
- Domain Driven Design
- 本を理解するのに参考文献が役に立つ
DDDのエッセンスとは
- ソフトウェア開発=学習と再構築
フローの中でいつシステムの理解ができたか?
学習とは
- 顧客の業務を理解すること
- 顧客の言葉で理解すること->ユビキタス言語
再構築とは
- モデルを共有すること
- 業務の理解を共有する
- モデルを元にソフトウェアを作る->業務の変更にソフトウェアが追随するため
大事な概念
ユビキタス言語(第1章)
- チーム内のすべてのコミュニケーションとコードにおいてその言語を用いる
- 図、ドキュメント、会話の中で同一の言語を用いること
モデル駆動設計(第1章)
- ソフトウェアを設計する際にモデルを基に設計する
- モデリングパラダイム
レイヤ型アーキテクチャ
イテレーティブなプロセス(第4章あたり)
戦略的設計
開発の中のDDD
システム分析
- 機能の階層に分解する
- DDDだから特別なことはない
構成図と個別の設計
- 機能間の関連と分析及び機能毎の設計
アーキテクトの場合
- 領域の特性を見極めて協会設計とIF設計
- データモデリング
プログラマーの場合
- 領域内での適切な設計
保守フェーズの中でのDDD
- DDDとはソフトウェアを改善するため手法
- 新規のプロジェクトでのみ適応する手法ではない
手続きからモデル駆動へ
複雑な業務
あらゆる機能で必要というわけではない
- 単純な業務=データスキーマの操作だけで表現できるなら手続き型で十分
技術面での難易度とは別
エンティティの先
- モデルによって捉える知識は名詞を見つけることにとどまらない。ビジネスの活動やルールもドメインにとって中心的。
- ユーザが理解できないモデルを作ってはいけない。それはモデルではない。
DDDで実践する時に役に立つ話し by 加藤 潤一氏
## DDDの進め方
- メンバー8名、8ヶ月間
プロジェクトが始まる前に
- プロトタイプを作成
- 主要なモデルのみ実装
ユビキタス言語と実装をプロトタイプで共有・説明
- 前提であるアーキテクチャの共有
- 大枠のユビキタス言語が共有できたらプロトタイプを捨てて新しく作り直した
スプリント内で使えるドメインモデルを実装した
- モデルをストーリーから探す
レイヤー化アーキテクチャに組み込む
- 放って置くと他のレイヤからDomainレイヤが侵食される
チームメンバーにDDDに関するアンケートをとってみた
DDDやってみて効果あった？
- 効果が無いと答えた人はいなかった
- エンジニア・非エンジニアの間で、コミュニケーションしやすくなった
- 新しいメンバーが参画してもコンテキストやモデル知識を共有しやすい
- レイヤー化アーキテクチャを採用したことでソフトウェアの構造が明確になった
苦労した点は？
- 全員がDDDを知っている必要がある
- リポジトリーパターンとシャーディングなどの技術的な問題と相性が悪かった
- DDD本が抽象的すぎて設計と実装が人によりけり
- ドメイン/非ドメインコードの区別ができるようになるのに苦労した
- エンティティのIDとDBMSのシーケンスとの相性の悪さ
読書会を実施した効果はあった？
- どちらとも言えないという人が一人いた
- ユビキタス言語の重要性を理解できた
- 知識に対する共通基盤が作れたという効果があった
次もDDDを採用したいか？
- どちらとも言えない=4、はい=1
- 規模や期間によってどの程度使っていくか分からないが、エッセンスは使っていくと思う
- プロジェクトによりけり
DDDの難しさ
- チームの全員がある程度DDDを理解する必要がある
- 同じ言葉でも捉え方は様々であり、問題が発生するまでわからない
- シャーディングなどの技術的な問題にぶつかった時にDDDと技術の妥協点を探す
まとめ・感想
- DDD本は途中まで読んで参加したが同じく途中で挫折する人多し。
- ソフトウェア開発の設計における心構えや方針なので知っておいて損はないかんじ。ただしチームで統一して適用するのはハードルが高い。
- オブジェクト指向、UMLモデリングなどの設計技法に対する十分な知識と経験がないとDDDは厳しい。
- ユビキタス言語やコアドメインの蒸溜などはモデリングというよりは円滑にプロジェクトを進めるためのテクニックに近い。
- 具体的に適用するのであればこちらが現実的か。