見出し画像

正しくモジュール分割するのは難しいという現実に向き合う

Showcase Gig Product Team Blog

この記事は、Showcase Gig Advent Calendar 2021 18日目の記事です。

こんにちは。Showcase Gigの @suzushin54 です。

バックエンドエンジニアとして、 O:der Table というモバイルオーダーのプロダクト開発をしています。

幸運なことに、10月27日に行われた「現場から学ぶシステム設計：座談会」で登壇する機会をいただきました！ そこでいただいたアドバイスやコメントと共に、イベントを振り返ってみます。

このイベントは Showcase Gig, Alp さん, LegalForce さんの 3社と、ソフトウェア設計の分野で著名な増田亨さんをお招きし、日ごろの悩みや実践していることを元にディスカッションする座談会形式で開催されました。 同じく登壇した 田坂 @yuuuutsk さんも 記事にしてくれている ので、そちらも併せてご覧ください。

トークテーマと経緯

「最近の悩み」を相談するセクションにて、『複数の境界づけられたコンテキストにおける共通ロジックの扱いについて』というタイトルでお話させていただきました。簡単にいうと、コンテキストは異なるのに同じになってしまう処理やモデルってどう扱うべきでしょうか、という内容です。

私たちのチームでは、新しいプラットフォームを利用してプロダクトを開発しています。プラットフォームはメニューや注文といったプリミティブな機能を提供するため、それらを組み合わせてプロダクトのバックエンドサービスを構築していく必要があります。今回はそのプロダクトバックエンドの設計の話になります。

それでは、内容を振り返っていきましょう。

私たちの扱うドメイン

私たちのプロダクトが対象とする飲食というドメインにはいくつもの業態が存在します。それらに柔軟に対応するために必要に応じてコンテキストを分割しています。先の動画やスライドでも触れているとおり、コンテキストが2つ登場します。今回その詳細は問題の本質ではないため、テイクアウトとイートインという一般的な単語を使うことにしました。

この2つのコンテキストに分割した理由としては、注文や決済といったサブドメインを考えた時、そこに異なるビジネスルールを確認できたためです。代表的なものとしては会計のタイミングや注文回数などが挙げられます。しかし、どちらも「商品」を注文するためのシステムですから、同じ属性や振る舞いを持つモデルが生まれてきてしまうことは避けられません。

内容への反応・意見

座談会に登壇していた他社のエンジニアの方からは、

「同様のコードであっても重複させている、重複上等！」という意見や、

「注文や決済もテイクアウトなどと同等に重要な概念ととらえて位置付けを変える」といった意見がありました。

Twitter では、「たとえ現時点で共通だったとしても、今後を考えて共通化させるべきではない」という意見が多かったようです。

これらは PoC 的な開発であるとか、初めから中長期的にサービスを展開していく予定があるなど、開発現場の状況によっても選択肢は変わってきそうです。

余談ですが、最近話題の書籍『セキュア・バイ・デザイン』でも、DRY 原則は “構文的な重複ではなく意味的な重複を避けるべき” という意図であること、“異なるコンテキストにおいてモデルを共有することで予期せぬ問題が起こりうる” ことへの言及がありました。

また DRY 原則 については、Twitter でもミノ駆動さんからご指摘をいただいていました。ありがとうございます。

増田さんの見解

増田さんからは、大きく 2つの意見をいただきました。

1つ目は、考えられるアプローチを記載したスライドに対してです。

「モジュール分割の工夫をしよう。設計とはそういうものである。」

目から鱗が落ちるような、なんとも明快な一言です。

私はここで、モジュールを統合して 1つのシステムとして扱うか、あるいはモジュール分割の観点を変える、という 2種類のアプローチを考えていましたが、後者の一択とのことでした。

そして2つ目は、考えられるアプローチの Pros/Cons に対する言及でした。

  • 「Pros として挙げられている "モデルの重複を排除できる" というのは視点が違う。」

  • 「モジュールを分割したときに、関心事を分離できていることが大事。共通の排除に目線がいくと間違った分割をする可能性がある。」

  • 「正しくモジュール分割するのが難しいというのは、これは Cons ではなく現実である。」

  • 「モジュール分割してみる。リファクタリングをしてみる。それを繰り返す。リファクタリングや実験のコストをいかに下げるかを考える。」

核心を突く言葉の数々に一同、静かに聞き入ってしまいました😅

そして、事業方針としてどういう方向に展開するつもりなのか。価値を出せるのはどういう方向なのか。それは1つの判断材料になるだろう、というアドバイスもいただきました。この向かうべき方向という点については、ちょうど私たちの中でも明確になってきたところだったため、今後の良い判断軸になりそうです。

反省と収穫

イベントを終えると、いつからか「正解を知りたい」、「失敗したくない」と思っていた自分に気がつきました。

けれど、そもそも正解などはない。

試行錯誤を繰り返して、絶えず変化する世の中とビジネスに対応できる柔軟な設計を日々追求するほかない、ということにあらためて気付くことができました。

そういえば以前、広木さんも 「Fail-Fast」 なのだと仰っていました。原理原則はここでも変わらないのですね。

最後に

日ごろ、機能開発に集中していると、じっくりと設計について議論する機会は少なく、悩ましい局面に遭遇してもコストやリリースの都合で無難な対応を取らざるを得ない、ということは多々あります。

また、頻繁に変更が入る開発初期、主に機能追加を行う中期、不具合修正が主となった安定期などでは、開発者が感じる設計の良し悪しは変わることもあるでしょう。設計原則やベストプラクティスとされているものを採用することは多いですが、実際の開発現場では理想どおりにならないこともめずらしくありません。

設計が悪く感じられたその時は見直しを行うべきタイミングであり、そのサイクルをすばやく回していく。それが事業を推進していく私たちエンジニアの務めなのだと、今回の座談会を通じて認識を改めることができました。

以上、Showcase Gig Advent Calendar 2021 18日目でした。また明日の記事をお楽しみに。

この記事が気に入ったらサポートをしてみませんか？