From 6866739191a475d7a39332d6a436a54cda340145 Mon Sep 17 00:00:00 2001 From: Ivan Dugalic Date: Sun, 17 Dec 2023 14:03:43 +0100 Subject: [PATCH] added Info on Event-Driven systems and that these are not supported within the traditional state-stored scenario --- docs/application/architecture.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/docs/application/architecture.md b/docs/application/architecture.md index f8972929..b28e90d6 100644 --- a/docs/application/architecture.md +++ b/docs/application/architecture.md @@ -65,7 +65,16 @@ The domain model is explicitly modeling `events` and `state,` and this opens som It is important to realize that your core domain logic does not have to change in order to transit from one flavor to another! -Fmodel exposes couple of types of repository interfaces/ports within the `application` module to support these two flavors: +Fmodel exposes couple of types of repository interfaces/ports within the `application` module to support these two flavors. + +:::info +- State-stored systems are using single canonical model for writing and reading/presenting, by default. +- Event-stored/Event_sourced systems are split to command and view/query models, by default. + +Fmodel is promoting robust event-driven systems only in case of Event-Sourced scenario. + +In case of State-Stored scenario, you are limited to Decider and StateStoredAggregate components only. View, MaterializedView, SagaManager components are not available/useful. +:::