This page provides an overview about various aspects of the architecture and de-composition of the system into functional building blocks. We have used domains (yellow) as know from the SOA era and the domain maps often used for entire application landscapes. Second, we sub-structured the large domain "Forwarding Airfreight" which contains the core business of our example logistics provider company. The blue boxes represent sub-domains. The orange boxes are still drafts and represent external companies / partners the logistics provider will interact with. Since we need to define the relationship to those "domains" as well, they are shown here, too.

First idea for microservices structure

A first idea is to provide a micro service for each domain or sub-domain in this diagram. The most interesting part will be the de-composition of the large domain "Forwarding Airfreight" into multiple microservices. We will investigate, if the this kind of structure and de-composition will make sense for this scenario and which consequences this might have.

Possible consequences from having a task and process-based system

Since we will have a task- and process-based system and also a corresponding case UI and therefore also integrate the Camunda BPM engine for case and process automation, we have another layer of complexity to tackle. 

How about the UI?`

As part of this project, we will also try to seperate the UI and let the services deliver parts of it as well.