『レガシーをぶっつぶせ。読者になるコード日進月歩しんくうの技術的な小話、メモ、つれづれ、など2019-05-11『レガシーをぶっつぶせ。現場でDDD!』に行ってきたよメモ行ってきたメモレガシーをぶっつぶせ。いってまいりましたのでメモ。今回はDX(デジタルトランスフォーメーション)レポートに取り上げられていた技術的負債の塊であるレガシーシステムに立ち向かうためのDDDということで現場のどろどろ感を出してくイベントという趣旨。各発表の感想ソフトウェアの核心にある複雑さに立ち向かう本日のオープニングで発表したスライドです。~Y!プレミアム・バックエンドシステムのリニューアル~イベントの資料をアップロードしました。複雑化したものとどうやって向き合っていくかを考えたときにDDDが最適解であると考えて導入していったなど、ちゃんと理由をもってDDDを取り込んでいったところなど経緯込みで参考になったDDDを行った副産物として責務分離を意識するようになり、分割することで他の人に使われる意識が強くなるので自然と整理されていく、というエピソードはなるほどなと思えた。Blog設計人材を育てるためにDDDをどう使うべきか遅ればせながら昨日の発表資料をアップしました。設計力がある人材を育てるにはどうしたらいいかという話。大きく複雑なシステムには一人では立ち向かえない、それへのカウンターパートとしてどうやって設計ができる人材を増やしていくかという設計(Design)とは何かというのは物を作る前に落とし込む行為という言い回しに非常に納得感があった期限やアウトプットが出てない状況で実装を進めろというプレッシャーを「実装圧力」という言葉で表現しているのが秀逸だったし、その実装圧力で設計が浅いものを作ってしまうという話も綺麗にまとまっていた。既存サービスを部分的にリプレイスしていくための過程とどういうことをしていったかを多角的に説明した話。実録!LOHACOにおけるDDDとCleanなArchitecture本日の登壇資料です!「実録!LOHACOにおけるDDDとCleanなArchitecture」@レガシーをぶっつぶせ。Languageビジネスルールの複雑さに立ち向かう本日の後半で発表したスライドです。詳細な実体と俯瞰モデルこの組み合わせの4つの領域を行ったり来たりする。説明文書/定義文書」「ビジネスルールの説明文書/定義文書」「ビジネスの全体像/事業戦略」としそれぞれどのような考えをもつといいかという話。「ビジネスルールの説明文書/定義文書」に関しては日頃からある利用規約や料金表など普段のビジネスの取り決め文章からどうやって作るかの脳内トレーニングをすればいざ自身の業務のときにモデリングするときにも活きる、という旨の話をされていた「ドメインモデルの全体像/戦略的設計」に関してはビジネス上の振る舞いの分類を知っておくことでどういうビジネスルールを構築するかを着想しやすくするための分類方法の紹介があった「ビジネスの全体像/事業戦略」に関しては自身の携わるビジネスが市場においてどんな状況であるかなどを把握しておくことでどういう変化や要求が起きうるかを予め把握できるなどの話があったこれらの4つの事象を行ったりきたりすると良い、という話で、たしかに磨かれるものは多いだろうなという感じだったもともと「変化に強いシステムの作り方」という話をされてきた増田さんだったがそこにさらにプラスオンで「変化の方向性をシステム化するビジネスから読み取るには」という話に展開されてきた感じがあり、すごく学びが多い話でした。xTECH(クロステック)パネルディスカッションクエスチョンに対して登壇者のコメント要約の形で載せていきます。同じことであれば経験値から見積もれるが、やれないことは見積もれない。慣れていけば見積もれるし学習曲線ができる。プロジェクトのサイズを小さくやり、DDDなど新しい試みは識者が支援して、わかりきったものは従来通りやってもらうなどで見積もりの精度を保つようにしていたQ.ユビキタス言語の管理ってどうしていますかだいたい全員がユビキタス言語を管理してない、リストを作ってみたがその後運用はできていない...という回答Q.(上の質問の続き)ユビキタス言語を管理しないことで問題は起きているか?ビジネスとエンジニアの間に仲介するレイヤーの人が増え、その人がいないと回らないという形になる用語の重複などが起きた場合は実際に軌道修正をかけてみて、それで治らない場合はその言葉でクラスを作ってみてつながりを考えてみたりするもともとリストを作るなどフラットに全部やるという方法論はとっていない。リアルに仕様を取り違えている場合は徹底的に掘り下げて向き合う。(おそらく言葉がすれ違うことで進めていくことの危険を回避するという話)Q.処理速度とのトレードオフはどれくらいありますか?(ゲームなど60~120FPSとかで導入できるか)Webパフォーマンスの文脈だとGoとかElixirで頑張るなどするし、インフラでカバーするなどの方策をとる。パフォーマンスを求められるところはDDDを諦めて分割するなどの方針をとるQ.コードが多くなりがちですが、テストコード等はどうしていますか?動的型付け言語(Rubyとか)、だと何が入ってくるかがわからないのでそれに対するテストコードが多くなりがちだが、型付きの言語やタイプヒンティングができる言語(PHP7とかPython3)であればそれらの手間がなくなり軽減できるので少なくなった型がある言語だとそこでガードができるのでテストコードは最低限になるテスト自動化という仕組みがない時代からやっているからテストコードは書いていない、ただし分岐が多くなる部分などはビジネス的にも大事な部分なのでしっかり手動で手厚く確認作業を行う。Q.Railsでうまくやる方法はありますか?勇気を出してリプレイスをしたほうが良いですか?RailsはActiveRecordが密結合で実現しているためDDDのモデリングの考え方と相性が悪く、レイヤードアーキテクチャをやろうとすると型がないことなどDDDの考え方が適応しにくいリプレイスに関しては一気にやらずとも少しづつやる方法があるのでやり方は考えてほしいQ.DDDなくても開発できるじゃんって言われときのベストな回答は?現在困っていないのであれば無理にDDDを採用しなくても良いDDDのメリットはビジネス側の作業量の感覚と現実のシステム開発の作業量の感覚が近づくこと、それにメリットが見いだせるか某社で取り組む際は中心メンバーとやってくれそうなメンバーをアサインして全体の2割が動いてくれるようにして全体を動かすように動いたQ.ユビキタス言語が浸透しない。ビジネスサイドが同じ意味で別の言葉を使う。何か対策工夫はあるか?どちらか正解、というよりはビジネスサイドで使われる言葉のほうに合わえせていくほうがいい部署によって同じ意味だが違う言葉、みたいな場合はドメインが違うと割り切って対応する全体感想メンバーや非エンジニアサイドへの理解の求め方は事例として貴重な意見が聞けた。ゲームのFPSの話はおそらく「ValueObjectのようなプリミティブなものをラッピングすることでオブジェクト生成コストが増え、1秒間に何回ループ処理ができるかというゲームにおいてはその重複生成が命取りになったりするんだけどそこに関してどういう考えか」みたいな意図の質問に聞き取れたので、これこそ言語のチョイスやうまくネイティブと相性の良いValueObjectの作り方を考えるなどになるので、言語のエキスパートの人の知見が必要そうな感じ。テストの話とRailsの話は言語選択によるミスマッチや、採用フェーズによって何を活かすかを考えさせられる部分が多かった。テストは結構Twitterでも意見がいくつかあって一考するところがありそう関連リンクドメイン駆動設計を取り入れてみて感じたこと。全体的にレガシーシステムにどう向き合っていくかという話でかなり濃い&学びの多い事例が多かったですQとDを担保する話は組織での人のアサインや立ち回りまで含めて秀逸な事例でした。最初と最後の増田さんの話は書籍「現場で役立つシステム設計の原則」のさらに先の話を聞くことができて、数々の現場を渡り歩いてきたシステム開発者の知見が集結している気持ちになりすごい学びがありました。型がない言語に人権のない話が続いてきて、安全に振り切る場合は型のある言語で構築したほうが安全なのかなという気持ちになった。(いまならJavaよりもKotlinのほうがnullのこと考えるとよかったりするんだろうか...)他の方のブログ記事レガシーをぶっつぶせ。blog「レガシーをぶっつぶせ。幸運にも致命傷で済みました【勉強会】「レガシーをぶっつぶせ。Mediumレガシーをぶっつぶせ。「レガシーをぶっつぶせ。等身大から1割増しレガシーをぶっつぶせ。「入門『状態』」という内容で登壇してきました。(3)はてなブログをはじめよう!shinkufencerさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。