拙い気持ちのアウトプット

私の気持ちをアウトプットする場所にしようと思っています

レガシーをぶっつぶせ。現場でDDD！に参加して

genbade-ddd.connpass.com

イベントに参加してきました。

かなり後の補欠だったので無理かと思ってましたが、前日に繰り上がって参加できました。

そもそもDDD（ドメイン駆動設計）について現状の自分の状態は、

  • 業務での利用経験なし（DDDでやってます！って言っているプロジェクトはあったが、中身は全然そんなことなかった）
  • 個人のPHP+Laravelプロジェクトで手探りで導入中
  • エヴァンス本未読…

という感じで、初心者もいいとこです。

会場はYahoo!さんのオフィスでした。

併設されていたコワーキングスペースは一般利用もOKとのことなので、機会があれば利用してみたいです。

lodge.yahoo.co.jp

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

株式会社ギルドワークス 増田 亨

www.slideshare.net

オープニングがあって、最初は国内DDDの第一人者でもある、株式会社ギルドワークスの増田さんのセッションでした。

レガシーなシステムはやり方によっては1, 2年で出来上がってしまうというのが、確かにと思う部分がありました。

完全にイニシャルのスピード重視で作ってもよくないし、きっちりかっちり数年がかりで作っても良くなるわけではないし、変更容易性を意識した設計が重要ということですね。

ドメインロジック ≒ ビジネスルール

ビジネスルール自体はそこまで複雑でない場合もあるが、ビジネスルールを適用する条件分岐が複雑にしていることが多い。

自分も以前ユーザーのロールや認可周りでぐちゃぐちゃになったコードを見たことがあったので、ちょっとわかりみがありました。

DDDはその複雑になりがちなビジネスルールにどう対応し、変化を実現していくかのための方法論というか概念なのかなと考えました。

あと印象的だったのは圧倒的に「型」が重要であるということ。

プリミティブな型ではなく、値の振る舞いを明確に定義した値オブジェクトを型として厳密に扱えるということは、DDDにおいてマストだということでした。

これも非常に納得のいく話で、プリミティブな型や型の曖昧な値が露出してしまった瞬間に、条件分岐が断片化してしまう可能性が出てきてしまいます。

増田さんは基本的にJavaで考えているとおっしゃってましたし、厳密にやるには静的型付けの言語を選択するのが賢い手かもしれません。

自分では主にPHPで書きますが、7系なら比較的型を厳密に扱えるものの、配列表現などではarrayをむやみに露出させないように気を遣うことが多く苦戦します。

Ruby（特にRails）ではこの辺がやりづらかったり、言語によってもDDDに対するアプローチは考えないといけないことが多そうです。

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

ヤフー株式会社 清水 将貴

続いてはYahoo!の清水さんより、実際にレガシーシステムをモダン化してリニューアルする（している）お話でした。

「どのように（How）」モダン化するのかではなく、「なぜ（Why）」モダン化する必要があるのかを考えるのが重要というのが非常に印象に残っています。

Whyに注意して考えた結果、変化に強いというビジネス目線と、改善しやすいというサービス目線があることに気づき、DDDというアプローチをとったとのこと。

どうしてもレガシーなコードを向き合っていると、モダンでイケてる構成にすること自体が目的になってしまいがちですが、気をつけたいと思いました。

あと全てを詳細に作り込むのではなく、重要なところはしっかり作り込み、そうでないものはざっくりやるのも大事というお話がありました。

重要かそうでないかをしっかり見極めるために、ビジネス要求の大きさ x 運用コストの大きさで考えるというのは合理的で非常に勉強になります。

ベンチャーでドメイン駆動設計をやるとどうなるか？ 〜Pythonで型に倒してみた〜

株式会社チームボックス 安西 剛

続いては具体的な話が聞けそうだったので、安西さんのPythonでDDD実践してみた話を聞きました。

実際に具体的なコードやディレクトリ構成を見せながら説明していただき、非常にわかりやすかったです。

Pythonでも3.5から導入されたType HintsとInteliJのPyCharmを組み合わせれば、型のある世界でDDDできるとのことでした。

とはいえ、特にWeb系で選択肢に上がりやすい動的型付け言語でいうとPHPやRubyもありますが、型という点に注目するとPHPにやや優位性があるのかなと感じました。

あとは開発のフェーズにおいて、0→1、1→10、10→100、100→∞とアプリケーションが大きくなっていくとき、10→…を超えてしまうと大きく設計などを戻せない境界線のようなものがあるというお話が、なんとなくですが共感できました。

10までの間にきちんと変化に強い設計を組んでおきたいところですね。

DeliveryとQualityを両立させるために僕らがやったこと 〜トラベルシステムの技術全面刷新〜

ヤフー株式会社 関口 岳志

www.slideshare.net

続いてもYahoo!さんからで、今度は関口さんによるセッションでした。

現実的に存在する制約の中で、品質の高いものを作りそれを維持し続けていくためにどうするかというお話でした。

特に刺激的だったのは、ビジネスサイドの同意と承認を得るために、改善前後のコードに対して同じ仕様変更を実施し、その工数差分を数値として出して改善を推進するための材料としたところでした。

コードと向き合う人はリファクタリングや再設計の必要性を肌で感じられますが、そうでない人にとってはただのリスクにしか受け取られないこともよくあることで、そのため改善系の工数はなかなか承認が降りないケースは過去にもありました。

関口さんのように具体的な数値で見せるのが最も効果的なのは間違いないのですが、なかなかパワーが要ることなのは間違いないので、尊敬します…。

また、どうしても必要になるのが中心となって設計を進める人と、同等レベルでその人の壁打ち役となる人というお話もありました。

もちろんメンバー全員が精通していればいいですが、一人が中心となって進めざるを得ないケースのほうが多いと思います。

そういったときに壁打ち役の人がいるのといないのとでは、中心になる人の負担が非常に大きく変わってくるので、ある意味中心となる人以上に重要な役どころかもしれません。

ドメイン駆動設計とマイクロサービス

ヤフー株式会社 三石 広樹

次は三石さんによるマイクロサービスを切り口としてDDDの導入に至った経緯を聞きました。

まずマイクロサービスありきで進めてしまった結果、変更に弱いサービスが出来上がってしまった失敗談を踏まえ、DDDと組み合わせることで変更に強いマイクロサービスを作り上げていった具体的な過程が聞けて、とても参考になりました。

技術要件が先行してしまった結果、ビジネスの要件に対応しづらくなるというのはどうしても起こりがちで、開発側からするとなぜうまく回らないのか…とかなり苦しい気持ちになるケースでもあります。

設計を検討する際に、テーブル構成とリレーションを意識してしまうことがよくありますが、そこから一旦離れてモデリングしていくというのはなるほどという感じでした。

言われてみれば自分でもテーブル構成をどうしても先に考えてそれに引っ張られがちだなと思ったので、気をつけていきたいです。

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

株式会社ギルドワークス 増田 亨

www.slideshare.net

増田さんのお話の後編でした。

ビジネスルールについて、4つの象限から捉える話が非常に興味深かったです。

どうしても小手先というか、具体的なドメインモデルの表現だけに目がいってしまいがちですが、現実世界でのビジネス的な視点や、ドメインモデル全体を俯瞰してみることなど、必要に応じて視点を変えて見ることで解決の糸口になったりするという内容でした。

あとはビジネスロジックを表現するための値オブジェクトの重要性、コレクションの操作を内包して操作処理の断片化を防ぐなど、非常に実践的な内容で勉強になりました。

また、さすがにビジネス視点での話も非常に納得感のある内容で、DDDとは切っても切れないものであることを再認識しました。

ぜひまた別の機会でも増田さんのセッションを聞いてみたいです。

パネルディスカッション&質疑応答

最後に、参加者からの質問に登壇者がパネルディスカッション形式で回答してくれました。

DDDに対する理解が得られないケースや、業務委託の人にどのぐらいお願いするのかなど、以前苦しんだ部分に近い内容もあって非常に自分得な内容でした。

（業務委託の人は切りまくる！とか強烈なご意見もあって、おおう…ってなりました）

あとはユビキタス言語の管理については、どこもあまりうまくいってないですよとか、自分でも以前管理に失敗してメンテできなかったケースがあってやっぱりそうなんだと言う感じでした。

最後に

DDDというやや抽象的なテーマで、なかなか実践的な内容に触れられる機会が少なかったですが、今回のイベントは全てのセッションが非常に実践的で、ためになるものばかりでした。

実際に導入する際のハマりどころや、失敗してしまった事例などが現場の方々の体験談として聞くことができて、今後の参考にできそうでした。

エヴァンス本トライします。