レガシーをぶっつぶせ。現場でDDD！に行ってきました #genbadeDDD
きっかけ
レガシーをぶっつぶせ。現場でDDD！に行ってきました。
正直、タイトル一本釣りな感じです。
こんな過激で魅力的なタイトルあります？
実際に現場でDDDに取り組んで、失敗とか反省とかあると思うんですよね。
それを共有してくれるとは、なんてありがたいんだ！
以下、参加時のメモです。
趣旨説明
DX(デジタルトランスフォーメーション)
2025年以降、最大１２兆円／年（現在の約３倍）の経済損失が生じる可能性 DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～（METI/経済産業省）
ここにもあるように、技術的負債に立ち向かうために、設計をちゃんとやろうということらしい。
しかし、特設サイトまであって気合入ってますね経済産業省。
きれいな理論より、現場のドロドロ感
うん、こういうの大好きなんです。
地に足ついてる感。
ソフトウェアの核心にある複雑さに立ち向かう
なぜドメイン駆動設計なのか 稼働後にいかに進化と成長が続けられるかが大事
常に進化と成長を続けられるような状態にしておくのはエンジニアの仕事だと思ってます。
できることなら、これにフォーカスして仕事をしていきたいものです。
型指向のプログラミング
型を厳密に定義することで、正確性というかビジネスルールを表現するという方法は、はじめて知ったときはやりすぎでは…と思っていたけど
最近コードをドキュメント化というか値の範囲、計算を表現するというのは非常に効率的だなと思うようになってきました。
面倒なチェックをコンパイラにお任せできるのがうれしいですよね。
ドメインエキスパート 新しい業務・プログラムに対してはドメインエキスパートはいない
新しい業務の建付けはエンジニアが入って、フローの整理とかルールの設定を主導するというのは本当にやるべきだと思っています。
業務はたいてい部署を横断したり、担当者を横断するので、そこを繋げて合理的に整理できる役割はエンジニアが意外といい位置だったりする。
計算を入出力から隔離する 計算に特化したアグリゲート
さらに、データをアウトプットするのがS3にファイルでなのかRDBなのかなどにかかわらず、抽象化できるといいのかなと思ったりしてます。
エヴァンス本
IDDDを読んでから約半年…そろそろ頃合いなのか…
抽象的な教えを試行錯誤しながら解釈したDDDの実践レポート
抽象的な教えを試行錯誤しながら解釈した DDD の実践レポート
DDDをあまり知らない状態からどのようにキャッチアップして実践したかという話 軽い感じの語り口で聞いていて何回か吹き出してしまった
多重度(タジュード)
その発想はなかった。自己紹介としてすごい印象に残る。
君のDomain層からは業務を感じない
これ、発言主の方はすごいセンスだ。
仕様から名詞や動詞を抽出して設計をする
具体的なやり方というか、試行錯誤の仕方を見習いたい。
仮定をして検証する、手法を変えてまた検証するというのは、実に理論的な進め方だと感じた。
ドメイン間の依存をつくるときは変わりにくい方に線を引く
これ、クリーンアーキテクチャの安定度の考え方に似てる気がする。
依存される数が多いほど、そのクラスの変更は少なくなるべきっていう考え方。
設計人材を育てるためにDDDをどう使うべきか
設計人材の育成の事例の解説
こういうのって、情報出てこないのでありがたいです。
設計人材って新鮮な言葉ですね。
自分が設計できる!=メンバーが設計できる
設計ができるって人が複数いても、音楽性が違ったりでうまくいなかいこともあるよね…(つらい)
メンバーに設計を振ってみる->思ったのが上がってこなくて->いら立つ->委縮する
個人的には勝手に自分の理想を押し付けるのがよくないのんな、って思う。
すり合わせもしないでお任せすると、そりゃズレるよな。って話。
みんなが信仰する宗教(設計の考え方)を決めようというのが解決なんじゃないかなと思ってます。
DDDによる設計を定着させるための方法 ドメインモデルで議論する 責務の分割と組み合わせを考える
この辺をレビューとか事前のすりわせの議題とするということですかね。
考え方をシンクロさせるというかすり合わせるみたいなのは重要そうです。
師匠の弟子のコミュニケーション 師匠の問いかけ力
もうすでに信頼関係というか師弟関係ができているなら、良いのだけれども
フリーランスの方に業務委託みたいなときにどうすればよいんだろうなぁ…
ちゃんと時間を確保する
まずは時間的余裕をつくるというのは、ほんと重要だよね。
師匠が途中で急用でいなくなっちゃうとさびしい…
すでにある実装を元にToBeのドメインモデルをつくる
師匠がファシリテートして、気付きを導くみたいなのはよさそう。
これが師匠の問いかけ力ということか！
あとコード->設計->コードみたいな多面的な進め方は、実際の設計やっている流れに似てるので力が付きそう。
設計力をどう測るか
面談とかでも、話すほうも聞くほうも難しくってここって何とも言えないよね…
いままで作ってきたシステムとか、発言っぷりから総合的に感じることなのかな…
師匠のDDDの設計人材育成を通して変わったこと トレードオフがあるような、微妙な設計判断を伝えることができた、 弟子とお互いに見解を述べてポイントを探ることができた
そういうところのシンクロって、重要だと思います。
レビューで合わせるとか、許容するとかあると思うけど、そこがすり合わせできてるなら最強だなと感じる。
劇的ビフォーアフター～BIGLOBEのDDDの昔と今～
太陽系戦略
何回かBIGLOBE殿の発表で見かけた図ですね。
開発部門全体での大方針がきまっていて、ちゃんと推進できてるんだろうなぁと感じる好きな図です。
のれん分け方式
ノウハウの共有って、勉強会とかだとあんまりできなくて、実際にやりながらのれん分けしていくのが現実路線だよなぁと思う。
一個前の発表の師匠弟子じゃないけど、そんなイメージ。
モデルの書き方 エンティティの分け方と属性名だけだと、齟齬が生まれる 情報を増やすために概念モデル->コンテキストマップ->ドメインモデルに分けて書く
図によって議論の範囲が決まるので、話題が発散しずらいというのはよさそう。
元々の課題がどのフェーズでどの関心ごとを議論すればよいのかというのを図を分けるというアプローチで実現したのが新鮮だった。
状態の表し方 状態ごとに必要な要素のみを持ったエンティティをつくる
null絶対なくすマンみたいな思想と似てるのかな。
私は状態をフラグとかenumで持ちがちだけど、その辺はよく考える必要がありそう。
チェックの実装箇所 Application層にチェックのロジックが漏れがち Domainにロジックを集約する
いつも悩むのがSPAとかの画面のチェックをどこでやるのかということ。
フロントがバックエンドのロジックに依存するのも嫌なので、今のところロジックの重複を許してるんだけど、うーん？
実録！LOHACOにおけるDDDとCleanなArchitecture
実録！LOHACOにおけるDDDとCleanなArchitecture/DDD and Clean Architecture at LOHACO - Speaker Deck
レガシーシステムにDDDとクリーンアーキテクチャを導入した話。
最近クリーンアーキテクチャ読んだので、タイムリーな話題ですね。
DDDが難解。抽象的なので何が正解なのかわからない 小さく始めるDDD
ひとつ前の発表でもそうだったけど、スモールスタートが良いんですね。
ユビキタス言語更新されない問題
用語が統一されていることが重要であって、一覧が更新されてないのは必須ではないのだろうけど…
新しい人が来たときとか困りますね、うーん難しい。
全員がDDDをやるという認識を持つこと
たしかに。
音楽性の違いがあると、進みが異常に遅くなるし、どっちつかずな感じになりそう。
仕様技術
Kotlin/Spring Boot使ってるので親近感ある。
フレームワークなんかと結婚するな
実際の話、Springに依存するとテストがしずらくなるんだよね。
DIとか依存とかがいっぱいあって、モック、スタブ刺すのが大変。
ドメインぐらいは簡単にテストしたいというモチベーションで、Springに依存させないのはよさそう。
ビジネスルールの複雑さに立ち向かう実践技術
ビジネスルールの複雑さと戦うということはビジネスの全体像/事業戦略とも関係すること 技術論だけではない
システム開発と事業戦略って同じ会社内でも、宇宙人かっておもうほど考えていることが違うと感じる。
その機会があるのはうれしいなぁと思う。
型原理主義者
ご本人から聞くのが新鮮すぎて、ちょっと笑ってしまった。
値オブジェクト(Fact-Rule-Goal)
何回も話を聞いているが、あんまり理解してない。
値オブジェクト間の変換ってどこに書くんだろうか。
具体的なコード、リポジトリにあるかな。
区分の設計
ビジネスで使われている概念の区分化というか整理は、実際要件定義に有効だと感じてます。
区分分けによって裏に隠れているビジネスルールが判明したりすることが実際にありました。
業務知識がわかる本
そこまで言われると読みたくなるよね
「業務知識ベース」でつくる要件定義入門
そこまで言われると読みたくなるよね。その２
さいごに
濃密な1日でした。
(内容濃すぎて、ちょっと後半疲れた…)
DDDについて多面的な知見が一気に聞けて、自分の考え方が整理できました。
- 開発に導入するには全員がDDDに取り組む必要がある
- 実際の開発に導入するには、小さく始めるのが良い
- DDDに正解はなく実践による試行錯誤で正解に近づくもの
この辺が今思ってることですかね。
