Aufteilen und Benennen Microservices

Question

Ich habe vor kurzem ein Nebenprojekt gestartet. Es sollte ein virtuelles Rezeptbuch mit den Möglichkeiten sein, Rezepte (CRUD) zu speichern und abzurufen, sie zu bewerten und zu durchsuchen. Das ist nichts Neues, aber ich wollte es als Desktop-Anwendung erstellen, um mehr über Datenbanken, Komponententests, Benutzeroberflächen usw. zu erfahren. Jetzt, da die Kerndomäne ziemlich fertig ist (ich benutze einen DDD-Ansatz) und ich die meisten CRUD-Repositories implementiert habe, möchte ich dies etwas erweiterbarer machen, indem ich die Kernfunktionalität online horte, so dass ich mehrere Backends schreiben kann (Desktop-Anwendung, Web-Anwendung, Web-API, usw.).

Service-orientierte Architektur (oder Microservices) klingen wie eine gute Annäherung an mich, das zu tun. Das Problem, vor dem ich stehe, ist, wie ich entscheiden soll, welche Teile meines Projekts zu einem separaten Dienst gehören und wie ich sie benennen soll.

Nehmen Sie die folgenden Teile des Projekts:

• Kerndomäne (Aggregates, Entities, Wert Objekte, Logic) ->Java
• Persistenz (DAOs, Repositorys, mehrere Datenbank-Backend-Implementierungen) - >Java
• Search (Suche nach Dienstleistungen, die für die Suche SQL-Abfragen auf der Persistenz DB verwenden) ->Java
• Desktop-Anwendung ->JS (Electron) oder JavaFX
• Web Application ->Flask oder Rails
• Web API (verwalten, bewerten, Suche nach Rezepten REST) ​​->?

Mein erster Ansatz wäre es, die Kerndomäne zu setzen, die Ausdauer, die Suche und das Web-api in ein einziges Teilprojekt und Host, die ganzen Stapels auf Heroku oder etwas ähnliches. Auf diese Weise können meine Kunden die Weboberfläche konsumieren. Die Desktop- und Web-Apps wären eigene Projekte. Die Desktop-App könnte die Kerndomäne gemeinsam nutzen, wenn sie beide in Java geschrieben sind.

Ist das ein gültiger Ansatz, oder sollte ich den ersten Service in kleinere Teile aufteilen? Wie nennen Sie diese Dienste?

Answer 1

Eric Evans auf GOTO 2015 Konferenz (https://youtu.be/yPvef9R3k-M) und ich 100% stimme ihm zu, beantwortet Ihre Frage. Der Microservice-Bereich sollte einen oder mehrere beschränkte Context (s) enthalten. Einschließlich seiner unterstützenden Klassen für Persistenz, REST/HTTP API, etc. Wie ich verstanden habe, ist der Microservice Deployment Wrapper über Bounded Context, mit dem Hinzufügen der Isolation, Skalierung und belastbare Aspekte. Wie Sie geschrieben haben, haben Sie Strategic Design nicht zur Definition von begrenztem Kontext verwendet. Also ist es Zeit zu überprüfen, bevor die App zu Teilen zerreißt.