マイクロサービスの分割と命名

Question

最近私はサイドプロジェクトを開始しました。レシピを保存して取り出し（CRUD）、評価し、それらを検索する機能を備えた仮想レシピブックであると考えられていました。これは新しいことではありませんが、データベース、ユニットテスト、UIなどの詳細については、デスクトップアプリケーションとして構築したいと考えていました。コアドメインはかなり完成しました（私はDDDアプローチを使用しています）。私はCRUDリポジトリのほとんどを実装しました。コアの機能をオンラインでホストすることでこれを少し拡張したいと思っています。デスクトップアプリケーション、Webアプリケーション、Web APIなど）。

サービス指向アーキテクチャー（またはマイクロサービス）は、そうするための良いアプローチのように聞こえます。私が直面している問題は、自分のプロジェクトのどの部分が別のサービスに属しているか、どのように名前を付けるかを決める方法です。

は、プロジェクトの以下の部分を取る：

• コアドメイン（集約、エンティティ、値オブジェクト、ロジック） - >Javaの
• 持続性（DAOに、リポジトリ、複数のデータベース・バックエンドの実装） - >Javaの
• 検索（検索のための永続DBにSQLクエリを使用検索サービス） - >Javaの
• デスクトップアプリケーション - >JS（エレクトロン）またはJavaFXの
• Webアプリケーション - >フラスコやRailsの
• のWeb API（RESTを使ったレシピを検索する、レート管理） - >？

私の最初のアプローチは、単一のサブプロジェクトにコアドメイン、持続性、検索やWeb APIを入れて、Herokuのまたは類似した何かでそのスタック全体をホストすることです。そうすれば、私のクライアントはウェブインターフェースを消費することができます。デスクトップとWebアプリケーションは、それぞれ異なるプロジェクトになります。 Javaで記述されている場合、Dektopアプリケーションはコアドメインを共有できます。

これは有効なアプローチですか、最初のサービスをより小さな部分に分割する必要がありますか？どのようにこれらのサービスに名前を付けますか？

Answer 1

GOTO 2015会議（https://youtu.be/yPvef9R3k-M）のEric Evansと私は100％が彼の意見に同意して、あなたの質問に答えました。マイクロサービススコープは、1つまたは複数のバインドされたコンテキストである必要があります。永続性、REST/HTTP APIなどのためのサポートクラスを含みます。 私が理解したように、マイクロサービスは、隔離されたコンテキスト上のデプロイメントラッパーであり、分離、スケーリング、および復元の側面が追加されています。 あなたが書いたように、あなたは有界コンテクストを定義する戦略的デザインを適用しませんでした。アプリを部品に裂く前にチェックする時間。