レガシーをぶっつぶせ。現場でDDD！に参加しました。 参加してみて、現場の生の声や体験談などなど聞けて初学者ながら良い刺激をいただきましたので熱が冷めきらないうちに感想をまとめてみました。
私の背景としては、昨年の今頃から増田さんの現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法を読んでDDDに興味を持ち、現在業務に導入できないか検討しているというレベル感です。
ソフトウェアの核心にある複雑さに立ち向かう / ビジネスルールの複雑さに立ち向かう
増田さん(@masuda220)
アプリケーションが複雑になるのは、ビジネスルールを適用するの条件に分岐が出てくるから複雑に
心当たりがあります。コーディングしていて複雑なビジネスルールがあるところは読み解くの大変だったり汚くなりがち… うまく記述していかないと、ほぼ使われないオプションのためにあらゆる箇所に新しいフィールドを加える…といった残念な設計に…
入出力と計算の分離
変換部分でなかなかコストがかかるなというのはDDDをかじっていて思う部分ではありますが、そうすることで計算モデルを純粋に保てるというのはまさに良い恩恵かなと思います。 逆にそこにあまりメリットが感じられない人に対してこの変換の手間を納得してもらうのもなかなか大変だよなぁと公演を聞きながら考えていました。 後のパネルディスカッションでもお話ありましたが巻き込んでいける人とそうではない人との関わり方をうまくハンドリングしていくのもDDDをやる上ではかかせないのかも…
型指向プログラミング
値の取り得る範囲での生成を強制することで安全に値を取り扱えて防御的プログラミングならず、コードがビジネスの本質に集中できるというのは現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法を読んだときから共感する部分でした。 テストについてはリファクタかけたときに元の仕様担保出来ていることを確認するため私は用意するのですが、値オブジェクトのテストは一般的には自明なので書かないのかな… また、どの粒度まで値オブジェクトとして用意するかという部分が悩むところではあって、例えばお金を取り扱う業務があったときに取り扱う金額の範囲でMoney型を定義するのはもちろんとして、数量を表すAmount型も合わせて用意するべきなのか、もし用意する場合は他の数量を取り扱うようなAmount型を使いまわして良いのか（Util, 共通モジュールのような取扱にならないか）でよく悩みます。
複雑さに本格的に立ち向かう
言語化できないもやもや（新しい概念）にうまく名前をつけられたときに、他の複雑さを持っていると整理していた部分についても同じ区分で表現でできることがわかりより良い整理ができる。といった体験があったため共感する部分でした。 コレクションのカプセル化の部分で、カプセル化したクラスに特定の操作やロジックがあるものはビジネスルールがまとまって扱いやすいので共感できる部分でした。 一方でコレクションクラス化を進めているとロジックが内部の値にアクセスするだけの貧血起こしているクラスも出来てきて、そうならないための切り分けや判断材料等など聞いてみたいと感じた次第でした。
抽象的な教えを試行錯誤しながら解釈したDDDの実践レポート
ほげさん（@suzuki_hoge）
何やらレビュー時に抽象的なフレーズが飛び交っている
入門してすぐがDDDの用語に圧倒されるというのはどこでもあるあるなのかなと感じました。
例に漏れず私も圧倒されていたるので松岡さんのブログや成瀬さんのボトムアップドメイン駆動設計勉強会に非常に助けられています。
名詞の抽出
名詞同士の関係性まではなんとなく見えてくるものの、振る舞いがよくわかっていないままコードを書く → アプリケーション層やインフラ層が膨らむ & モデルが貧血起こしてGetterだけあるという状態に私も陥りました 同じ流れたどっていて入門者あるあるなのかなと感じていました。
ドメインに集める？
私の場合はDB操作はインフラ層に持っていっていたものの更新のための判定ロジックも一緒にインフラ層に散っていたり、それぞれのRepositoryに永続化を依頼するため条件がアプリケーション層に散っているといった状態です。 ほげさんの取られていた動詞に着目してinput param → prosess → output paramの形を徹底的してドメイン層にロジックを集めていくというアプローチは目からウロコでした。
境界を決める
知りすぎているドメインを切断した流れが、Evans本の独立したクラスに当たるのかなと考えながら聞いていました。 私がまだ実践できていない部分なので今聞けてよかったというのと、事業戦略を考慮して変えたい願った部分だけを変えられるよう設計するという言葉が強く印象に残っています。
DDDサンプルコード ライブリファクタリング
いろふさん（@irof） 増田さん（@masuda220） https://github.com/system-sekkei/isolating-the-domain
どういう意図でサービスを呼んでいるのかというのを明示的にするためにControllerからCoordinatorというクラスを作成しそこに操作の組み合わせを記述していくというものでした。 機能を変更するときの影響箇所の特定が簡単になるので安心というのがいいなという印象でしたが、あまり多用すると私の場合はビジネスルールの関心事も外のCoordinatorに流出させてしまいそうな気がしたので、採用する際はビジネスルールなのかシステムの都合なのかを慎重に判断した上で操作を記述すべきだと感じました。 Jigというツールや1つのパッケージのファイル数max10個ルールなど実践的な話を生で聞けたのも収穫でした。
劇的ビフォーアフター 〜BIGLOBEのDDDの昔と今〜
曽根さん
のれん分け方式
リードしている人だけでなく暖簾が分けられるほど他のメンバーも成熟して行けているのが凄い成果だなと。DDDに限らず新しい技術の伝播するのに良いなと感じました。
Pull Requestが大荒れ
Beforeの部分でプルリクのコメントでそもそもの責務の話から入るのエネルギー奪われて気が滅入るなと…辛い…
状態の表し方
ファクトリで状態の加工処理を行っているというのが勉強になりました。
チェック
チェック処理をドメインサービスにまとめているという話が新鮮 Applicatin層にチェックロジックが漏れていく話はほげさんのお話聞いているときも私やりがちだなぁと感じていた部分ではあり、あるあるなのかなと。 ドメインサービスはチェック項目毎にドメインサービスを作るイメージなのか気になりました。
実録！LOHACOにおけるDDDとCleanなArchitecture
さとうさん（@dskst9） なかむらさん https://speakerdeck.com/askul/ddd-and-clean-architecture-at-lohaco
ストラングラーアプリケーションパターン
そういう名前がついているんですね。ワードを初めて聞いたので勉強になりました。
抽象的であっているかいないかもわからないままやっていくしかない
結構いろいろな方がこの状況に遭遇して日々手探りしている部分ではあるのかなと感じました。手探りでやっているのは自分たちだけじゃないという話を聞けただけでも収穫でした。
コードが語り始める
そのレベルまで進めて行けているのが素晴らしく、よりコードが自然言語の振る舞いに近づくとそうなる？
Web層
モジュールの構成でインフラ層の配下にWeb, DB…のようなモジュールを私の場合切ってしまいそうで、あえてインフラとWebを別物として切り分けているのが印象的でした。
質問：振る舞いではないのでGetter書きたくないがほかレイヤへの情報の開示どうしているか？
利用する側に内部の情報を展開するためだけにGetterを書きたくない（振る舞いではないから）というのは私も同じことを思います。 私はJava, Springで開発する機会が多く、増田さんに質問する機会があったのでこの問題に対してどうされているのかお伺いしたところSpringのDirect Field Accessを使っているとおっしゃっていました。 かとじゅんさんの記事でもこの問題に触れられていますね。 一般にはどうするのが良いのでしょうか。
おわりに
参加して良かった、同僚にも次があればぜひ行こうと言える充実した内容でした。 皆様の話を聞くとレガシーを潰そうというよりもうまくレガシーと付き合っていっているというように印象が強かったです。 技術的な用語や内容にフォーカスされがちだけど、それだけがソフトウェア開発やDDDじゃない。人付き合いを始めとしたコーディング以外の戦いの場（むしろそちらのほうが主戦場かもしれない）もあるとひしひしと感じました。 今回の勉強会を企画、運営してくださった方々、登壇者の皆様、参加させていただき誠にありがとうございました
