A small group project to learn about "event-driven services and architecture", especially the concepts Event Sourcing (ES) and Command Query Responsbility Segregation (CQRS). A small e-commerce shop implemented as a series of microservices, built upon technologies like Spring Boot, Cloud and Apache Kafka. Part of the exam for the master's program module "Advanced aspects of distributed systems" (FAVS) at Hochschule Hannover, WS20/21.
Currently there is a lack of code documentation because this project was hacked together very quickly.
We should add a bit of commentary, esp. to code parts with high (technical) impact.
Currently, most of the POMs are very copy-paste due to the fast velocity of this project.
Extracting some of the dependencies and plugins into the parent POM makes this whole project more wieldable, and all children POMs more readable/configurable/handable/understandable.
Currently, we have no form of CQRS in our system. To achieve this, some/all microservices need to be split into a command and a query part.
If we are not splitting all microservices because of some reason, we should first document that reason and explain why only some services have been split.
The following two would be a good idea to split at the least: CustomerService and ProductService.
The document/diagrams should explain how Event Sourcing and Command Query Responsibility Segregation are used exactly and what they enable (code/technical-wise).
For example, this could showcase a sequence diagram on what happens when a user is creating his own account in our system, i.e. which services are interacting together, how does CQRS / ES help here.
Either in some form of an architecture.md [0] or ADRs [1].
Create an document that describes how to interact with our system once it is started. It should atleast contain:
describing business use case
showcasing a few business work flows
define how to interact with the system: provide cURL / Shell scripts and show how to use GUI.
Write down that it is possible, that certain services might need a while before they are available. Docker-compose creating ... done does not mean, the service is started and reachable. Even after the log output ends, the gateway might need a while for the routing of requests -> concrete services takes hold.
Does not mean, that the service has crashed, only that it is currently unavailable due to routing of gateway being to slow (might a be local/machine thing, due to constrainted resources available). { "timestamp": 1615409020742, "path": "/customers", "status": 503, "error": "Service Unavailable", "message": "", "requestId": "fa12285a-1" }
Currently, we only have create and retrieve (the C and R in CRUD) functionality for our entities (only R for product).
The other basic operations of managing and interacting with data should be implemented, too.
deleteCustomer
updateCustomer
deleteOrder
updateOrder
Atleast for the customer and order entities.
We could declare that our product entities are managed by some other form, i.e. an internal system which an warehouse worker uses to enter new products.
Extracting the fixed logic from the CustomerService, moving it into a parent module and generalizing it into a reusable function allows us to make sure every CRUD operation + event emission on any entity will be handled in the same way.
Currently, we need to write an MessageConverter for each Message.
Which does not seem appropriate considering the fact that this is a 1:1 relationship, i.e. for each event we need to write a new MessageConverter, which simply bloats amount of classes.
Ideally we would convert all our events back to simple POJOs, as Spring Cloud Stream seems to be able to convert these without problems from/to JSON.
But this does seem a bit backwards, as there definitely should be an easier way for this.
Find better way for converting events <-> json to avoid having to write an converter for each event.