レガシーをぶっつぶせ。現場でDDD！2nd 「インプット＜アウトプット！」参加ログ
参加してきたので感想を書く
オープニングトーク
DX（デジタルトランスフォーメーション）についての話。 2025年以降の技術的負債の経済損失がが12兆円／年にのぼる。 comemo.nikkei.com つまり、レガシーなシステムを改善すること、負債化を最小限に留める設計が重要。 という話だった。
B:モデル・コードの変更がどう表現されるかハンズオン
内容
格安SIMのモデリングとコーディングハンズオン。
モデルとコード間を行ききして、モデルを改善していく流れを体験する。
全体の流れとしては下記のようなものだった。
- 格安SIMの仕様書に対し仕様書に出てくる文字をモデルとして書き出す プラン、オプション、料金、月額料金など
- まずは愚直にコードに落とし込む
- テストがグリーンになるように実装する
- コードとモデルを比較し、コードとの乖離がないようにモデルを更新する
- モデルで依存関係を確認し、依存が多いところをリファクタリングする
- リファクタリングの際に概念が足りないことが発覚したり不要な概念が見つかる
以下繰り返し
学び
- モデル図で依存関係を俯瞰する
- コードからモデル図を生成するツールを使う
UML クラス図 - ヘルプ | IntelliJ IDEA - サービスはドメインの情報を使う、逆方向の依存は無い（ドメインの変更は全体に影響する）
- 言語機能を使ってimmutableなvalue objectを作る
https://martinfowler.com/bliki/ValueObject.html
普段はVSCode,TypeScriptなので下記のようなものが使えそう
vscode-ts-uml - Visual Studio Marketplace
QA
Q.どれくらいの頻度でドメインモデルを育てるか？
A.新しい機能追加のタイミングでドメインモデルもリファクタしている
サービスにif文雅出現しているのでドメインサービスをつくる。判断はドメインの役割。
Q.モデリングに使う道具は？
A.紙と付箋
ただし全体像は紙で表現できないので一部のみ
資料
資料は後日TechBlogに公開していただけるとのこと https://style.biglobe.co.jp/archive/category/TechBlog
C:モデリングワークショップ 〜割り勘ドメイン編〜
内容
割り勘システムのモデリングと実装のハンズオン。
ユースケースの大枠が決められており、それに従いドメインモデルの作成->実装を行う。
詳しくは下記リポジトリのREADME.md参照
https://github.com/j5ik2o/warikan-domain
学び
- モデリングが難航した
作業全体をハンドリングする人が必要だった。(前のハンズオンは主催者側のドライバがいたが今回は全員参加者だった。)
モデリングの認識合わせが曖昧だったため話の方向性が定まらなかった。（モデルに全員同意していることが大事） - 区分という概念はEnumとして表現する（現場で役立つシステム設計の原則でも見た）
- 値の表明と型の表明
- 内部データをそのまま返すGetterはドメインの文脈では使わない、何らかの計算をして返す。（ただしI/Oの文脈では使うこともある）
資料
それぞれのチームが考えたモデルは以下のようになった。
クロージングトーク
大規模開発とDDDについて参加者同士で話した。
学び
開発者の人数について
5~6人が適切（肌感）でそれ以上は増やさない。
それ以上増やすときはドメインを増やす。
負債化を防ぐ方法について
- ペアチームを作り交代でモブプログラミングする
2ペアチームで1人ずつ交代していき、モブプログラミングする。すると4人全員がドメインの知識を把握し、コードを把握できるようになった。 - プロジェクトに対してチームを交代制でまわしていく
プロジェクトAに対し最初はチームAが担当し、一定の期間がすぎるとチームBが担当する。こうすることで引き継ぎ資料が必ず作られるようにする。
これは自チームに取り入れてみても良いかもしれない。
チーム全員交代は難しいかもしれないけどドメインチーム間でメンバー交換とかやってみると、別ドメインの理解が深まったり、新しいメンバーによる発見があるかもしれない。
ドメインの粒度について
ユーザに機能を届けるまでのリリース間隔が長い場合はチームの粒度を見直す。
リリースサイクルを評価関数とする。
一つの変更に多くのチームが関わる状況ならばチームの粒度を見直す。
ドメインの理解について
ドメインごとのKPIが決まるはずなのでKPIについて考えてドメインの理解を深める。
ドメインと組織構造について
ドメインの編成に伴い組織構造も変更が生じる。
感想
- 例題をもとにモデルとコード間を往復するハンズオンを通してモデルを育てていく感覚をつかめた
- 次のアクションとして実際の業務のモデリングをやっていく
- 変更に強い設計についてもう少し具体的に学ぶ必要があることがわかった
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者:エリック・エヴァンス
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
実践ドメイン駆動設計 (Object Oriented SELECTION)
- 作者:ヴァーン・ヴァーノン
- 出版社/メーカー: 翔泳社
- 発売日: 2015/03/17
- メディア: 大型本
