DRYにするか分けるかについて

DRYにするかどうかはよく誤って判断されることが多いと思います。 スタートアップ時には先のことを想定していないケースが多く、サービスの規模が拡大してから問題が発生することが多いかと思います。

そこで、どういうものはDRYにすべきで、どういう場合にきちんと分けるべきかまとめてみます。

アプリケーション内の処理

言うまでもなく、1処理1メソッドにすべきです

同じような処理が複数見られる場合は1箇所に集約します。 ただし、DRYにするのはあくまで処理であって、種類が別のものまでDRYにしてしまうと特定の種類の場合しか不要な処理が他の種類の場合でも無駄に動いてしまうでしょう。 種類毎にアプリケーションの受け口は分けて、各種類の受け口から使用するものは共通にしておくと、後で柔軟に対応できると思います。

アプリケーション(リポジトリ)をまたいでの共通の処理はライブラリとしてアプリケーションとは別のリポジトリにすると良いと思います。 そうするとマイクロサービス化しやすいと思います。

汎用的な処理は自作よりもgem、標準のライブラリを使用するのが良いと思います。

サービスの対象の種類

例えば、不動産であれば、賃貸マンション、新築マンション、新築一戸建て、中古マンション、中古一戸建てなどのことで、飲食業界ではランチや宴会などのことです。

これは基本的にはサービス毎明確に分けて、マイクロサービス化すべきです。

最もやってはいけないのは種類をパラメーターにしたり、フラグで分けることです。
そうしてしまうと、いずれサービスは崩壊するでしょう。
サービスの裏側は種類を見るif分等でぐちゃぐちゃになるでしょう。
また、世の中にリノベーションマンション、部ランチ等の新しい種類が追加された場合にはそれだけ別に分けてしまったり、既存の種類を消したい場合には工数が膨大になり、リスクが高くなります。 つまり、世の中の変化に脆弱なアプリケーションになるでしょう。

インフラ

各サービスで使用する標準のインフラのソースを作成すべきでしょう。 そうすれば、各サービスのインフラ構築が数分で済みます。 また、各サービスで共通の変更が必要な場合はソースを修正して、各サービスに適応するだけで済みます。

それぞれのサービスがそれぞれインフラを構築してしまっている場合には各サービスで調査が必要になることもあるかもしれません。

一番望ましいのはサーバーレス構成のインフラのソースを作成するのみで、AmazonGoogleにインフラはお任せすることだと思います。

ドメイン

ブランド戦略によりますが、基本的に各サービスは企業orサービスドメインサブドメインになると思います。 マイクロサービスの場合も同様ですがサービスの実態に合わせるのが良いかと思います。 ドメインをすべて同じにしてしまうとロードバランサの障害で全サービスが停止しないように不必要に良いインスタンスにして、余分なコストが発生するでしょう。

サービス名称

例えば、WantedlyがサービスのWantedlyをWantedly Visitに変更したように、スタートアップ時には会社名がサービス名になっていることが多いと思います。

また、Wantedlyというブランドは人材系のサービスに自身を限定してしまっている印象があります。

ブランドやサービス名の変更は大きな影響があるため、最初から先を想定する方が良いかと思います。

ブランドの戦略にもよるのですが、ブランド名を分けて、ブランド価値低下の影響範囲を少なくするのか、既存の確立されたブランドのカチを新規サービスでも享受するのかは判断が分かれるところだと思います。

どちらにしろ、企業名やサービス名はサービスの領域を限定しない抽象的な方がよいと思います。

その点、AmazonGoogleはよく考えられたものです。 AmazonならIT分野に進出してAmazonWebServices、Googleなら、ホームデバイスGoogle Home。企業名が抽象的なためにどの分野にも進出しやすいと思います。