コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

『レガシーをぶっつぶせ。現場でDDD!』に行ってきたよメモ

レガシーをぶっつぶせ。現場でDDD! にいってまいりましたのでメモ。

今回はDX(デジタルトランスフォーメーション)レポートに取り上げられていた技術的負債の塊であるレガシーシステムに立ち向かうためのDDDということで現場のどろどろ感を出してくイベントという趣旨。

各発表の感想


ソフトウェアの核心にある複雑さに立ち向かう

感想

  • ソフトウェアにおける複雑さの根源に対する向き合いかた、切り分け方の考え方の話
  • 変更容易性が高いことは開発におけるすべての面において有効というのを改めて感じさせられた
  • ドメイン駆動設計本格入門のときにも語られていた「ドメインロジック」を「ビジネスルール」に置き換えるということをより濃く話されていたし、明確に置き換えていたので前回以上に考え方がスッと入った
  • エヴァンス本の3章と4章は何か困ったときの出展として読めるようにするべきとい

関連リンク


レガシーシステムからモダンな環境への移行 ~Y!プレミアム・バックエンドシステムのリニューアル~

感想

  • 現在のレガシーシステムの現状、そしてそこに対してどうやってDDDでアプローチしていっているかという経緯の話
  • 機能としてどんどん継ぎ足しされていった「Yahoo!プレミアム」に対してどうやってドメインを分け、適応していくかという話
  • 複雑化したものとどうやって向き合っていくかを考えたときにDDDが最適解であると考えて導入していったなど、ちゃんと理由をもってDDDを取り込んでいったところなど経緯込みで参考になった
  • DDDを行った副産物として責務分離を意識するようになり、分割することで他の人に使われる意識が強くなるので自然と整理されていく、というエピソードはなるほどなと思えた。

関連リンク


設計人材を育てるためにDDDをどう使うべきか

感想

  • 設計力がある人材を育てるにはどうしたらいいかという話。
  • 大きく複雑なシステムには一人では立ち向かえない、それへのカウンターパートとしてどうやって設計ができる人材を増やしていくかという
  • 設計(Design)とは何かというのは物を作る前に落とし込む行為という言い回しに非常に納得感があった
  • 期限やアウトプットが出てない状況で実装を進めろというプレッシャーを「実装圧力」という言葉で表現しているのが秀逸だったし、その実装圧力で設計が浅いものを作ってしまうという話も綺麗にまとまっていた。
  • 師匠と弟子という形でペアプロ形式を取るのは非常にいい取り組みだと思ったし、やはり言語での継承だと情報量が大きくなってしまうトピックはペアでやる形式が一番時間効率いいものだなという感じに思えた

関連リンク


QualityとDeliveryを両立させるために僕らがやったこと

スライドは公開されたら貼ります

www.slideshare.net

感想

  • 既存サービスを部分的にリプレイスしていくための過程とどういうことをしていったかを多角的に説明した話。
  • DDDの手法でドメイン分析を行い、ドメインを分けることで作るものの構造分析ができているのはDDDの本懐という感じ
  • 増田さんのワークショップを経験されていたので、そこでの考えを生かしている部分に関しての説明が丁寧で「いびつな形でもいいのでアウトプットを出す」「役に立つ部品を見つけることが最優先」など増田さんのDDDの考え方が反映されている感じでした
  • 新技術の導入に対して、チーム内に識者がいないので専属の壁打ち用のメンバーを外からアサインするというのは予算管理とか考えたらあんまり思いつかない手なので「なるほど、そういうのもあるのか!」という事例
  • キレイを維持する、また重要じゃないコンポーネントと重要なコンポーネントをある程度の表建てして判断するという手段をとっているのはちゃんと体制を敷くことに尽力しているという印象を受けた
  • カナリアリリースをするできる仕組みを整えることで、ミニマムスタートをうまく進めていく、旧実装と新実装を両方実装して実際に掛かった工数を比較して新実装の成果を定量的に示すなどのパワープレイはただただすごいと思わされた
  • 疎結合、高凝集を実現するためにBFF的な役割や、DBへレイヤーへの接続に関しても層を設けるなど責務分離をかなり意識したレイヤ構造にしていたにもかかわらず、レイヤでの実装が増えているにもかかわらず工数がトータルでは減ったという話はすごいなと思った
  • V字モデルでテストができるようになった部分など、いろいろ聞いてみたいことはたくさんあったがそこらへん聞きそびれてしまったので何かの機会があればまた伺いたいし、スライドが公開されたときはまた見直したい

関連リンク


実録!LOHACOにおけるDDDとCleanなArchitecture

感想

  • 軽量DDDとCleanArchitectureを採用した事例
  • 複雑なロハコのドメインに関してどうやって挑んでいったかという経緯と実践が込められている
  • 腐敗防止層を設けて頑張るという戦略をとったがどうしてもそこの辛さが出てきた話はどこにでもある話なんだなという感じ
  • DDDは倣うより慣れろ、というのは心理だし抽象的な概念は実践を伴って現実的に活きるものだなという感じ
  • Kotlinを採用するという選択肢に関してもうちょい掘り下げて聞けばよかった
  • 即効性のあるプラクティス(ValueObject)とかはどこでも有効というのは確かにという感じ

関連リンク


ビジネスルールの複雑さに立ち向かう

感想

  • ビジネスルールとどうやって戦っていくかを4象限で分け、「ドメインオブジェクトの設計と実装」「ビジネスルールの 説明文書/定義文書」「ビジネスルールの説明文書/定義文書」「ビジネスの全体像/事業戦略」としそれぞれどのような考えをもつといいかという話。
  • ドメインオブジェクトの設計と実装」に関しては具体的にどういうコード記述をするかという方法論の話でドメイン駆動設計本格入門のときの際にも語られていた作り方の話
  • 「ビジネスルールの説明文書/定義文書」に関しては日頃からある利用規約や料金表など普段のビジネスの取り決め文章からどうやって作るかの脳内トレーニングをすればいざ自身の業務のときにモデリングするときにも活きる、という旨の話をされていた
  • ドメインモデルの全体像/戦略的設計」に関してはビジネス上の振る舞いの分類を知っておくことでどういうビジネスルールを構築するかを着想しやすくするための分類方法の紹介があった
  • 「ビジネスの全体像/事業戦略」に関しては自身の携わるビジネスが市場においてどんな状況であるかなどを把握しておくことでどういう変化や要求が起きうるかを予め把握できるなどの話があった
  • これらの4つの事象を行ったりきたりすると良い、という話で、たしかに磨かれるものは多いだろうなという感じだった
  • もともと「変化に強いシステムの作り方」という話をされてきた増田さんだったがそこにさらにプラスオンで「変化の方向性をシステム化するビジネスから読み取るには」という話に展開されてきた感じがあり、すごく学びが多い話でした。

関連リンク


パネルディスカッション

エスチョンに対して登壇者のコメント要約の形で載せていきます。

Q.チームのメンバーがDDDに興味を持たず、やる気をしめさないときはどうメリットを伝えればいいか

  • 一緒に1ヶ月ぐらいは勉強したりペアで開発する機会を設けて進めたりした、という体験談があった
  • モチベーションって人それぞれなので、ちゃんと人事制度に埋め込むべき、という意見
  • 2つのパターンがあって「DDDって伝えないでいく、(書籍の)リファクタリングとかでも語られていることはビジネスルールに関する話なのでそういう切り口で話す」「聞いてくれるひとでも最初で全部は伝わらないものなので、そこはそういうものだと思ってやる」という話があり、最後に「正面切ってドメイン駆動設計って話すぎないほうがいい」という旨の話があった

Q.DDDで開発する際、リリース日程や作業工程をどのように見積もってどのように計画立ててるか

  • DDDは関係なく、見積もりをちゃんとやるという意見
  • 同じことであれば経験値から見積もれるが、やれないことは見積もれない。慣れていけば見積もれるし学習曲線ができる。
  • プロジェクトのサイズを小さくやり、DDDなど新しい試みは識者が支援して、わかりきったものは従来通りやってもらうなどで見積もりの精度を保つようにしていた

Q.ユビキタス言語の管理ってどうしていますか

  • だいたい全員がユビキタス言語を管理してない、リストを作ってみたがその後運用はできていない…という回答

Q.(上の質問の続き)ユビキタス言語を管理しないことで問題は起きているか?

  • ビジネスとエンジニアの間に仲介するレイヤーの人が増え、その人がいないと回らないという形になる
  • 用語の重複などが起きた場合は実際に軌道修正をかけてみて、それで治らない場合はその言葉でクラスを作ってみてつながりを考えてみたりする
  • もともとリストを作るなどフラットに全部やるという方法論はとっていない。ただリアルに仕様を取り違えている場合は徹底的に掘り下げて向き合う。(おそらく言葉がすれ違うことで進めていくことの危険を回避するという話)

Q.処理速度とのトレードオフはどれくらいありますか?(ゲームなど60~120FPSとかで導入できるか)

  • Webパフォーマンスの文脈だとGoとかElixirで頑張るなどするし、インフラでカバーするなどの方策をとる。
  • パフォーマンスを求められるところはDDDを諦めて分割するなどの方針をとる

Q.コードが多くなりがちですが、テストコード等はどうしていますか?

  • 動的型付け言語(Rubyとか)、だと何が入ってくるかがわからないのでそれに対するテストコードが多くなりがちだが、型付きの言語やタイプヒンティングができる言語(PHP7とかPython3)であればそれらの手間がなくなり軽減できるので少なくなった
  • 型がある言語だとそこでガードができるのでテストコードは最低限になる
  • テスト自動化という仕組みがない時代からやっているからテストコードは書いていない、ただし分岐が多くなる部分などはビジネス的にも大事な部分なのでしっかり手動で手厚く確認作業を行う。

Q.Railsでうまくやる方法はありますか?勇気を出してリプレイスをしたほうが良いですか?

  • RailsActiveRecordが密結合で実現しているためDDDのモデリングの考え方と相性が悪く、レイヤードアーキテクチャをやろうとすると型がないことなどDDDの考え方が適応しにくい
  • リプレイスに関しては一気にやらずとも少しづつやる方法があるのでやり方は考えてほしい

Q.DDDなくても開発できるじゃんって言われときのベストな回答は?

  • 現在困っていないのであれば無理にDDDを採用しなくても良い
  • DDDのメリットはビジネス側の作業量の感覚と現実のシステム開発の作業量の感覚が近づくこと、それにメリットが見いだせるか
  • 某社で取り組む際は中心メンバーとやってくれそうなメンバーをアサインして全体の2割が動いてくれるようにして全体を動かすように動いた

Q.ユビキタス言語が浸透しない。ビジネスサイドが同じ意味で別の言葉を使う。何か対策工夫はあるか?

  • どちらか正解、というよりはビジネスサイドで使われる言葉のほうに合わえせていくほうがいい
  • 部署によって同じ意味だが違う言葉、みたいな場合はドメインが違うと割り切って対応する

全体感想

  • メンバーや非エンジニアサイドへの理解の求め方は事例として貴重な意見が聞けた。
  • ゲームのFPSの話はおそらく「ValueObjectのようなプリミティブなものをラッピングすることでオブジェクト生成コストが増え、1秒間に何回ループ処理ができるかというゲームにおいてはその重複生成が命取りになったりするんだけどそこに関してどういう考えか」みたいな意図の質問に聞き取れたので、これこそ言語のチョイスやうまくネイティブと相性の良いValueObjectの作り方を考えるなどになるので、言語のエキスパートの人の知見が必要そうな感じ。
  • テストの話とRailsの話は言語選択によるミスマッチや、採用フェーズによって何を活かすかを考えさせられる部分が多かった。テストは結構Twitterでも意見がいくつかあって一考するところがありそう

関連リンク


全体を通しての感想

  • 全体的にレガシーシステムにどう向き合っていくかという話でかなり濃い&学びの多い事例が多かったです
  • QとDを担保する話は組織での人のアサインや立ち回りまで含めて秀逸な事例でした。
  • 最初と最後の増田さんの話は書籍「現場で役立つシステム設計の原則」のさらに先の話を聞くことができて、数々の現場を渡り歩いてきたシステム開発者の知見が集結している気持ちになりすごい学びがありました。
  • 型がない言語に人権のない話が続いてきて、安全に振り切る場合は型のある言語で構築したほうが安全なのかなという気持ちになった。(いまならJavaよりもKotlinのほうがnullのこと考えるとよかったりするんだろうか…)

他の方のブログ記事