トーク

本トークでは、イベントストーミングを活用したオブジェクトモデリングの実践が開発プロセスとアーキテクチャにどのような変革をもたらしたかについて詳しくお話しします。

「どのようなオブジェクトを実装するのか」
この単純な問いに私たち開発者は多くの悩みを抱えています。

イベントストーミングの結果として得られるモデルはこの問いに対する解答の示唆に富んでいます。
その有用性を認め、私たちは過去２年間、組織的にイベントストーミングに取り組んでまいりました。

もちろん、ただイベントストーミングを採用すれば、それですべて片付くといったものではありませんでした。

イベントストーミングの採用は開発プロセスを一変させました。
アーキテクチャの選定基準を変えました。
組織的に取り組むには多大な努力と適応が求められました。

本トークでは実地での経験を基に、イベントストーミングによるモデリングの採用がどのようにプロセスやアーキテクチャの選択肢に影響を及ぼしたのかについて共有します。

◆お話すること
・イベントストーミングの流れと基本要素
・イベントストーミングの図はどのようなオブジェクト指向プログラミングの実装に落とし込まれるのか
・CQRS+ES との親和性
・もともとの開発プロセスがどのように変化したか
・アーキテクチャの選定基準の変化
・ポジティブな影響とネガティブな影響
・プロセス変更などに伴う組織的な痛みとその対症療法

オブジェクト指向設計を理論としては知っていても、実務にどのように応用すれば良いのかピンとこないという方向けに、弁護士ドットコムにおけるオブジェクト指向設計の実例を紹介します。

SOLID原則のうち、以下2つの原則を中心に実例を交えてお話しします。
単一責任の原則(SRP)
依存性逆転の原則(DIP)

読後感
オブジェクト指向設計の概念は理解しているが、実務にどのように落とし込んでいったら良いのか悩んでいるエンジニアの方々。
このセッションは、オブジェクト指向設計の実例を知るとともに、サービス開発にどのようなメリットがあるのかがわかる内容になっています。

概要）
弊社がOOC2020に出展した際実施したアンケートでは、モデル図を作成していないか、作成してもスケッチにとどまっている方が大半という結果でした。この傾向はいまも変わっていないようです。たしかに、モデル図を描くよりコードを書いて試したほうが手っ取り早い場合もあるでしょう。しかし、実はモデル図を活用したときの旨味に触れたことがないために、スケッチ＋コードが当たり前の方法だと思っている人もいるのではないでしょうか。
また、みなさんの中には、納品物として工程ごとの設計書を求められ、モデル図を作成している方もいるでしょう。そういう方は、モデル図間の整合を図ることや、前工程のモデルの情報をみて、人手で後工程のモデル図に入力するのが煩わしいと感じたことがあるでしょう。
一方で、多くのみなさんは、アプリやテストを書くのにオブジェクト指向プログラミング言語や手厚いフレームワークを使っているはずです。つまり、分析からテストに至るまで、オブジェクト指向の知識と経験なし済ませられるわけではないことも、承知しているわけです。ということは、モデル図には、みなさんがモデル図を活かす方法を手に入れれば、開発の役に立つ余地がまだまだたくさんあるのではないでしょうか。
このセッションでは、上に挙げたような、あまりモデル図が活用できていない方に向けて、モデル図の利用シーンや、モデル図を活用する方法を紹介します。

想定する聞き手）
ほんとうはモデル図を作成した方がいいと思っていながら、実務では作成しなくなってしまった人
開発を依頼したり、保守したりするのに、いまの仕事のやり方ではシステムを俯瞰するのがしんどい人
スケッチとしてのモデル図は作るけど、成果物には残していない人
もうちょっと実装の助けになる設計成果があったらいいなと思う人

話さないこと）
UMLや各図の記法の細かい説明

・レガシーコードにDDDの考え方を取り入れたいけど、どこからどう手をつけたらよいかわからない
・DDDを取り入れてみたが、いろいろな概念や設計パターンがどんな課題を解決するかを理解して上手く適用できているか自信がない

そんなふうに感じたことはありませんか？

今回は、コドモンにおいて、レガシーコードのDDDを取り入れたリファクタリングを、具体的にどのように進めているかをご紹介します。

昨年リファクタリングをしつつ機能改修を行った際の生々しい実例を通して、DDDの設計パターンを取り入れようとしてつまづいたこと、そして、その結果として得られた学びを共有したいと思います。

レガシーコードに立ち向かいながら「より良い設計」を目指すみなさまにとって、少しでも参考になれば幸いです。