最近私はサイドプロジェクトを開始しました。レシピを保存して取り出し(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アプリケーションはコアドメインを共有できます。
これは有効なアプローチですか、最初のサービスをより小さな部分に分割する必要がありますか?どのようにこれらのサービスに名前を付けますか?
単一の制限付きコンテキストとサポート機能を含むマイクロサービスについて考えると、これらを分割する方がはるかに簡単です。私は境界が定められたコンテキストを定義していませんが、プロジェクトの範囲はそれを本当に保証するものではありません。コンテキストマップを描かなければならない場合は、単一のコンテキストになります。私は永続性とクエリを提供する単一のサービスとしてすべてを展開するのが良い選択だと思います。 –