This page details the current architectural design of the entire system, if this changes, this page should reflect those changes (and specify why those changes where made).
Table of Contents |
---|
A general solid, project-independent, documentation of the microservice architecture can be found here: http://microservices.io/patterns/microservices.html
Of course our project's architectural structure is an implementation of an abstract design and therefore has some differences, implementation choices and/or nuances.
The diagram on the right is an attempt at visualizing the architecture.
Challenges related to the architecture: challenges as a result from the architecture that arise through implementation / development. For the project related challenges see the project plan.
The single most challenging aspect of having a (micro)service oriented architecture is the impact it has on development, deployment and testing: It gets a lot more complicated. For now this is solved by making use of docker and vagrant, but this should be kept in mind for the future.
As mentioned on the microservice pattern page, achieving data consistency between multiple services that are together part of a single request (edit) can prove to be troublesome, as each have their own database and can run into their own errors.
Suggested is an event driven approach, although currently there is probably not anything in place for this.
Having multiple independent microservices can make it easier to develop a microserivce (as well as assigning a team per microservice), eventually these independent services need to work together for the system to function. To this end clear standards should be set, both in terms of workflow (see project plan) and implementation.
Implementation standards:
Name | Date | Design |
---|---|---|
Core independent | 2017 | With the addition of traefik and the registry there is no longer a real 'core' module. Some artifacts of the previous design remain. |
Monolithic core | < 2017 | The older design, while also deemed as having a microservice architecture, was in reality more of a hybrid: It had a more monolithic core combined with several microservices that could be plugged in. The current design is more enterprise level with more in-dependability between services while lessening the monolithic nature of the core microservice. |
Points that should/could be discussed about the architectural design can be noted down here until resolved. Discussion on these should place take in a dedicated discussion issue on JIRA (GENERAL).