bergdola
commented
1 year ago The data which needs to be transfered depends on the different use cases and how the data model is split between the microservices. According to domain driven design, I’d suggest to split the data model into aggregates, i.e. grouping enteties in the domain model, that are strongly coupled to each other, together.
As a first step, I’d try to identify different scenarios and think about the following:
- Which data is needed in the context of these scenarions?
- Which microservices are involved in these scenarios?
- How is the data transfered between these microservices?
After that, a GraphQL schema file to specify the API between frontend and backend can be created, probably one schema per microservice.
For the API between the microservices, the events need to be identified and documented, e.g. as CloudEvents (see cloudevents.io).
As QA responsible, I’d like to establish acceptance tests in addition to unit tests. The scenarios mentioned above are a good starting point for this and will be described in more detail using Gherkin syntax to describe test scenarios and to explain the logical progression of the interaction.
The different aspects mentioned above should be documented using text-based files, e.g. using markdown syntax. This allows to review, discuss and approve changes via PR. What are your suggestions where to store these files? What do you think about an architecture repository?
Description
The developers need to discuss what dataflow there will be between the frontend and the backend, as well as between the different services. A general data format for communication between different services and between frontend and backend should be decided. The APIs do not need to be fully designed as a part of this issue.
Sub-issues / Children
https://github.com/IT-REX-Platform/template-microservice/issues/6 https://github.com/IT-REX-Platform/template-microservice/issues/8