エンティティサービスは複雑さを高める

独立系ソフトウェアコンサルタントのTareq Abedrabbo氏によると、エンティティサービスはマイクロサービス・アンチパターンだという。その主な理由は、浅い（shallow）モジュールを作ってしまい、提供する機能に関してインターフェイスが複雑になるためだ。

エンティティサービスでは、システム内のエンティティ（名詞）を定義してからモデル化する。たとえば、アカウントサービス、注文サービス、顧客サービスといった具合だ。これらのサービスは通常、エンティティを操作するCRUDライクなインターフェイスを持つ。

このようなCRUDライクなアプローチをとるために、エンティティサービスには重要なビジネス機能が含まれていないことがよくある。それどころか、浅いモジュールになり、複合的あるいは有用な抽象化をもたらさないのだ。機能要件を実現するためには、結局のところ、これらエンティティサービスを結合することになる。

エンティティサービスというのは、概念的に小さいけれども浅いものです。内部状態を操作したり公開したりすること以外、ほとんど何もしません。役に立つことをするには、たいてい組み合わせる必要があります。その意味で、本当に分離・独立しているとは言えません。

複数のデータソースにアクセスする必要がある複雑なクエリの場合、エンティティサービスの範疇から外れて、たいていは、それら自体のデータ上に個別のサービスもしくはビューとして実装されます。

すぐれた抽象化は、不要な詳細を最小限にして隠蔽し、システムについての考え方をシンプルにします。エンティティサービスは、それがもたらす複雑さを考えると、お金をかけるだけの価値を提供しません。

こうした「浅い」エンティティサービスは、最終的に、非常に結合したコンポーネントの集合になる、と彼はいう。これは運用において負担になる。より多くのコンポーネントを、デプロイ・スケール・モニタリングする必要があるためだ。また結合度が高くなると、1つの機能を実現するために多数のマイクロサービスをデプロイする必要があり、リリースプロセスは難しくなる。

単一障害点ができる可能性もある。多数のサービスが相互に依存していると、どこか1つに障害が発生するだけで、システム全体がダウンするおそれがある。

エンティティサービスをどう組み合わせたらよいか即座にはわからないため、概念的複雑さも生まれるという。多くの場合、システムの至るところでサービスの結合が発生し、わかりにくくなるためだ。

また、破壊的変更も起こりやすくなる。

エンティティサービス、すなわち「浅い」サービスは、一般的に、公開するインターフェイスと実装する機能との間に、意味のある調停や間接参照を提供しません。システムのクライアントは、データベースまでずっと、サービスの実装詳細とは無関係に結合されます。このような場合、インターフェイスと実装間のバッファが足らないため、サービス実装者が何も壊さずにシステムを修正あるいは最適化するのは、非常に困難になります。

システムをマイクロサービスに最適分割するための、たった一つの方法は存在しない、と彼は結論づける。しかし、いくつかベストプラクティスをアドバイスしている。ビジネス要件から設計を導くこと、情報を効果的に隠蔽すること、マイクロサービス間の共有コンテキストを避けることなどだ。そして、分割は、単一障害点ができるのを避け、システムの一部を独立にスケール可能にし、1つのマイクロサービス境界内に留めることで新機能を実装しやすくする。