aheusingfeld
commented
2 months ago @mrtnlhmnn this sounds very similar to #35. Can we combine these?
Open mrtnlhmnn opened 1 year ago
aheusingfeld
commented
2 months ago @mrtnlhmnn this sounds very similar to #35. Can we combine these?
Modularization and Distribution Chapter 3 ("Modularisierung") needs to distinguish much more clearly between a) internal modularization and b) distribution.
Cf https://github.com/isaqb-org/curriculum-flex/issues/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 ...)