DDDについては言葉だけ、浅ーく知っていたつもりが、完全無知・実践皆無であったことが判明、ほぼ知らない言葉ばかりで面食らった(よって下のメモも誤りあるかも)。キャッチアップからスタートし地道に取り組んだ実例に現場導入のリアリティを感じた。ドメインパターンという考え方は目から鱗。「スタイルガイド本」は早速熟読したい。
イベントページ:https://rosca.connpass.com/event/334002/
DDDを突き詰めていったら、イベントソーシングに流れ着いた話
高丘 知央さん 株式会社ジェイテックジャパン CTO
- 書籍『達人プログラマ』:アーキテクチャは生き物、建築というよりもガーデニングに近い
- アーキテクチャも常に成長しないと老朽化する
- 少しずつでも継続向上していくことが組織・個人成長にとって重要
- DDD導入の動機
- FatVC、スキーマ駆動開発など、business logic が肥大化しメンテ大変
- 会社で本買って勉強。はじめメンバー間で理解浸透に差があり苦労しつつ、結果的にテストが書きやすくなり、メンテナンス性が向上した
- 課題があり、さらに改善を進めた
- チーム分かれてDDD経験をもとにした振り返り、KPTA
- 「集約」、immutable data model、リッチな値オブジェクトを導入し改善
- チームを超えたモブプロ参加、全体のレベルアップにチャレンジ
- なぜイベントソーシングを使い始めたか
- 既存チームはDDD+RDBで改善続けている
- CTOとして、さらに良くできる全体改善の新アーキテクチャの開発を開始
- いつ、誰が、どのように変更したかが分からない追えない課題 → イベントソーシングなるものがあるらしい
- イベントソーシングとDDDとの関係:データを削除せずトレースを行うからデバッグが楽になる
- イベントソーシング:Greg Young の提唱(2014年 Goto; Conference)
- ハードル高いが、DDD実践がいつの間にかできていたと感じられる
- OSS「Sekiban」として公開した
- 鉄道思考プログラミング(Railway Oriented Programming)に対応
コンテキストマップの継続的な活用に向けて
東 優太さん 株式会社TOKIUM プロダクト本部 開発部 イネーブリング
- コンテキストマップとは
- DDDの戦略的設計手法のひとつ
- 境界づけられたコンテキスト間の関係性を明らかにするもの、全体の知性を理解できるようにするもの
- 抽象化されたことで上層部と目線を合わせやすくなった、今後のプロダクト計画をコンテキストマップ上で会話
- 一方、コンテキストマップがコードと一致しているか
- 古いコードはそもそもモジュール構造がなかったり、
- あってもモジュールとドメインとが一致しなかったり
- 例:後で捉え方が変わったが、リネームできない、など
- 周知不足やミスで意図しないモジュールができたりもする
- どんどん形骸化されていく
- 解決方法
- マルチプロジェクトビルド:思ったよりしんどい、依存の制限が特に厄介
- 少しずつでもなんとかしたいいい方法はないだろうか、、
- 書籍『ソフトウェアアーキテクチャの基礎』「アーキテクチャ適応度関数」
- 自動的に検証するための仕組みを作らなければいけない、自作しても良い
- いっそやることを減らそう、コードの配置変更だけに絞ってみた
- @tokiumjp/arch 作った
- yamlとディレクトリ構造が一致しているかを検証
“深いモデル“を実現するためのドメインパターンの探求
山田 佑亮さん 株式会社ispec CTO
- デザインパターンをドメインに適用しドメインをシミュレーションする
- デザパタ=技術的な課題を設計で解決するパターン(実装前提の設計パターン)
- コードがドメインをシミュレーションできている → ドメインエキスパートにとっての小さな変更 = コードにとっても小さな変更
- ドメインパターンを探求する意味
- デザパタに出てくるような課題がドメインにも出てくるのであればそれをそのまま当てはめられる
- ドメインパターンをいくつか持っておけば、ドメインを明快に表現した深いモデルへの近道になる
- 現状見えている、ドメインパターンになりそうな事例を紹介
- XX最適化パターン
- 最適化が事業価値にある場合、そのロジックは時間経過で変わりうる
- 変わる変わらないを切り分けて、変更容易性、テスト容易性を担保する
- 最適化ロジックがシステムの強みになっている場合、変更が多く入るので適用価値あり(最適化ロジックやめようという話にもなりにくいので)
- 抽象化ブロックパターン
- カスタマイズ性の高いソフトウェアに対し、それぞれの要素を抽象化することで、要素の多さをカプセル化する
- ユーザーにとってのカスタマイズが柔軟でそれが強みになっているケースに適用価値あり(抽象化によるレバレッジを活用可能)
- XX最適化パターン
軽量DDDはもういらない!スタイルガイド本でDDDの実装の基礎を学ぼう
プログラミングをするパンダさん BASE株式会社 Product Dev Div シニアエンジニア
- 軽量DDDがなぜ批判される?
- DDD Reference
- 上部:戦術(実装パターン)・下部:戦略(アーキ・モデリング)
- 上部だけを導入することが「軽量DDD」→ エンジニアもビジネスや業務ドメインに目を向けようというDDD本来のメッセージが薄まる
- 軽量DDDとはOPPのプラクティスをDDDから学ぼうとする態度
- OOPプラクティス別にDDDから学ばなかくても良い
- 勉強する際の落とし穴:読書会しても理解度に差がある、実践できる人とできない人が生まれる
- 「実務活用のイメージがわかない」
- 理解と実践にはギャップが生じる、チーム学習に対する課題
- DDD Reference
- 「スタイルガイド本」について
- 書籍『オブジェクト設計スタイルガイド』
- 「ドメインモデル貧血症」がどんな状態か、コードベースで理解できる
- スタイルガイドを紹介しているだけだが、カバー範囲が広くてDDDと相性良い
- DDD入る前の基礎になる
- スタイルガイド本を読んだ後は、戦略パートに集中できる
- チーム導入したスタイルの事例例を紹介
- 「『リーダブルコード』の次に読むべき書籍」
- OOPの理解度を統一できる
- レビューコスト大幅減
- 何を実現すべきか?の議論にフォーカスできる
質疑応答
DDDを知らない人が多いチームで、どのように浸透させていくか?
- ひとりでやるより、モブプロで一緒にやるのが効果的(高丘さん)
- コードに近い話が多いが、ユビキタス言語とかそっちが重要。チームの中の対話が開発・POで分断するのが起きがち、POとの会話では技術的用語でなくユビキタスに基づいて話すなど(東さん)
- 自分たちで手を動かさないとドメイン駆動設計は価値を内面化できない。全体として、モブプロ・イベントストーミングをしっかりやっていく。会社のコンテキストに合わせてインプット、講義的なものを粘り強くやる、この繰り返しを半年1年かけてやっていく(山田さん)
- 既存の事業・コードはすでにある状態:自分たちの事業がどこで一番お金稼いでいるか、価値提供しているかを確認する → そのコードが一番ごちゃついていると思うので、どう綺麗に再設計するのかを考えていく、戦略戦術のちょうどいい実装ができると思う(パンダさん)