restructure "modularization and distribution" ... and a general remark on the curriculum's structure

[mrtnlhmnn]

Modularization and Distribution
Chapter 3 ("Modularisierung") needs to distinguish much more clearly between
a) internal modularization and
b) distribution.

Cf #35

ad a) Modularity inside a deployment monolith tackles the internal component-based structure - both taking the domain-specific ("fachliche") and technical structure into account.
So this should talk about component-based software, moduliths, concepts like Onion / Clean / Hexagonal architecture and DDD's tactical design.

ad b) Distributing the monolith into a distributed application is a separate, different step. With that, one gets into the wonderful and magical world of distributed systems. One has to deal with problems, challenges like latency, network issues, consistency, inter-service communication and all kinds of the https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
In the current curriculum, modularization is not well and really distinguishing between these two different steps and concepts a and b.

---

If this is better addressed, the chapter 4 ("Integration") should go with the chapter 3 b): Defining services, infrastructural concepts (ESB, Kafka, message bus, and challenges/issues like security, latency, communication and interaction, messaging, EAI patterns, quality of service, backpressure, DDD's strategic patterns etc. etc. etc.)

---

Chapter 5 and 6 - define as requirements
The current curriculum tackles a lot of different topics. From component-based construction over distribution up to operations.
The scope is not quite clear. FLEX's main topic should be "How to build and construct a flexible architecture - either as a mono/modulith or a distributed system".
The topics around "Installation / Rollout" (5) like CI/CD and "Operations" (6) should be addressed with that in mind - hence as requirements on what kind of architecture is needed and appropriate. These important topics should drive the architectural decisions as requirements.

The current curriculum addresses these topics quite waterfall-like. Example: When going from a mono/modulithic system to a distributed one, operations undersees a lot of challenges as such a distributed system is much harder to monitor and operate on. This aspect should go be addressed inside the chapter on distribution. But not as a separate topic later in the agenda.
(Yeah, I know that the training can sort topics differently than in the curriculum but still ...)

[aheusingfeld]

@mrtnlhmnn this sounds very similar to #35. Can we combine these?