■はじめに
これは、2018/09/26のイベント、レガシーコードにドメイン駆動設計で立ち向かった 5 年間の軌跡についてのメモです。
自分は元来Java系のプログラマなのだけど、最近スクラムチームの立ち上げなどをやっていたりして、フワフワっとした気持ちで参加しました。
資料からのピックアップ、講師の方の補足説明や、QAの中で特に気になった点を中心に書いています。
公開資料は、後々読み返しても理解しやすく、神資料と言われているようです。
内容についての詳細は、他の方が書いいらっしゃいますね。
[レポート]レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡 #DDDAlliance
■要点
■■前身の取り組みは、開発プロセス改革で、アジャイル(スクラム)の導入だった
西さんの資料から。
2011までに、杉森さんを中心とした大きな舵切りが行われたとのことです。
その後の取り組みとして、生産性向上を目指し、いろいろ変えていく一貫でのDDDへ取り組まれたとのことです。
■■最初は、ドメインモデリング(本来業務)にフォーカスするため、雑音部分(横断的関心事)のライブラリ準備から始めた
西さんの資料から。
結果、最初のプロジェクトは、ライブラリ作りに終始し、リリースに至らず失敗に終わった。。
とのことですが、挫けず立て直されていますし、「アプローチとしては間違っていなかった」という文脈で話されていたと思います。
■■チームや組織のスケール、育成のためにはのれん分け方式
西さん、奥野さんの資料から。
エンジニア育成のために、ある程度経験を積んだチームを分割して、未経験者を混合するというものです。
■■最近の取り組みは、RDRAによる要件定義からのDDD
西さんの資料から。
ここ1年くらい取り組まれているとのことです。
■■ドメインからリポジトリ引き剥がし
小林さんの資料から。
ドメイン欠乏症との戦いの一環で、ビジネスロジックの同定とドメイン集約の結果、APサービス→ドメイン→リポジトリのよくあるパターンとなった。
ドメインでリポジトリがDIされるパターンは、テスタビリティが低く、辛かったので変えたそうです。
(Mockによるテストコードをと考えてたら、思った以上に大変になったとのこと)
結果、リポジトリのDIをいっこ上に引き上げて、APサービスでワイヤリングするといった実装になり良いかんじ。継続中とのことです。
。。ビジネスロジックの塊から副作用(永続化とか)を取り除いてロジックのテスタビリティを上げるアプローチは、"副作用ゼロ設計"と呼べますね。
(特にDIのないセカイではそうしないとテストコードがつらい)
■■日本語クラス、メソッド名 of 外部IF is DSL
小林さんの資料から。
つらい現実からドメインを守る取り組みの一貫。。いわゆる外部IFとのインピーダンスミスマッチの吸収方法かと思います。
複雑な外部IF仕様と、自分たちのドメインの間にConverterクラスを置くというものです。
IF仕様をそのまままコード化! 日本語クラス名!、プロパティ名!!、並びも合わせて!!!って、DSLみたいなものですね。
。。そういえば日本語命名自体は、昔、日本語XML(!!)の外部IFで、JAXBを使ったObject/XMLマッピングを試みたことがあります。
■■XML地獄からJavaへ
小林さんの資料から。
MyBatisのMapper XMLって書くの大変だし、間違いがコンパイラ検出されなくてつらいから変えたとのことです。
要は、DBのデータ型→ValueOject変換をAdapterクラスで行うってこと。
。。このあたり、歴史的に、べた書き→宣言的→やっぱりコードでしょ!っていう変遷たどっていますね。
■■ドキュメントよりチームの共通理解大事
奥野さんの資料より。
規約やガイドのドキュメント整備を考えたが、エンジニアが思考停止するのでやめたとのことです。
チーム全体の共通理解をはかること、育成に力を入れているとのことです。のれん分け方式しかり。
■■育成は講義方式より練習問題方式 and レビュー
奥野さんの資料より。
実際にモノをつくるので、分からないところが具体化されて良いとのことです。
業務の関心事とシステムの関心事の区別が大事なので、そこが学べるようなコンテンツにしているとのことです。
また、レビューア(既存メンバ)の気づきなどもあり、チームのスキルアップにもつながっているとのことです。
■■エヴァンス本は敷居が高い
奥野さんの資料より。
がおススメとのことです。
■■We're Hiring!
奥野さんの資料より。
圧倒的にエンジニアが不足しているとのことで切実そうでした。
■こぼれ話
- 初期のころ、t_wadaさんのこと良く知らずに講師(?)として招いた
- (ドメインモデル、ビジネスロジックなどに関して)Confluence、ドキュメントは破綻します。コードに落とせ!
- 細かいバリューオブジェクトとか嫌になるんじゃ? →意外と平気
- 「経験してないのにイヤだ」をどうにかする必要がある→極端なこと、厳しめなことやって感覚をつかむ
- 外注依存はしているけど、(アジャイルを前提にした)準委任契約としている。会社の区別なく育成しているし
- のれん分けによる育成期間は、3ヵ月は短すぎる、半年～1年かな
- 特にでかい外部IF仕様は、A3両面2ページ
- 増田さんは、図(ドキュメント)嫌い、コード好き
- エクセル嫌い問題(いい意味(?))...みんな開きたがらない
- レガシーコード(独自言語!)の分析は、外注してます。。せっかくお金はらうのだから、やりたくないところをまかす
- 100万行のプロダクションコード vs 100万行のテストコード 書きすぎじゃね? →まださぼってる感ある
- TDDやってるの? → No, 主にQA目的 but 間違いそうな実装はTDDで
- クラス、メソッドの粒度・サイズの規約などある? →無い
- 標準化や規約よりもチームでの対話を
- DDD始めたころは、増田さんの「俺がルールだ」的な指導だった
■私感
- 今まで自分が携わった開発の答え合わせ的な感じがして楽しかったです
- 話の節々でアジャイル(スクラム)が根付いている感じがしました
- トランザクションスクリプトの群れの中や、DIのないセカイでも頑張って行ける気がしました(してない)