{"id":13546977,"url":"https://github.com/AntonioFalcaoJr/EventualShop","last_synced_at":"2025-04-02T19:32:20.375Z","repository":{"id":36959084,"uuid":"380824433","full_name":"AntonioFalcaoJr/EventualShop","owner":"AntonioFalcaoJr","description":"A state-of-the-art distributed system using Reactive DDD as uncertainty modeling, Event Storming as subdomain decomposition, Event Sourcing as an eventual persistence mechanism, CQRS, Async Projections, Microservices for individual deployable units, Event-driven Architecture for efficient integration, and Clean Architecture as domain-centric design","archived":false,"fork":false,"pushed_at":"2024-01-09T19:11:00.000Z","size":16189,"stargazers_count":285,"open_issues_count":14,"forks_count":38,"subscribers_count":11,"default_branch":"release","last_synced_at":"2024-01-24T06:40:06.203Z","etag":null,"topics":["architecture","clean-architecture","cqrs","ddd","ddd-architecture","domain-driven-design","dotnet","dotnet6","dotnet7","eda","event-driven","event-sourcing","event-store","eventsourcing","eventstore","masstransit","microservices","reactive","reactive-programming","uncertainty"],"latest_commit_sha":null,"homepage":"https://github.com/AntonioFalcaoJr/EventualShop/blob/release/README.md#bulb-about","language":"C#","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/AntonioFalcaoJr.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2021-06-27T19:41:45.000Z","updated_at":"2024-07-13T18:35:56.300Z","dependencies_parsed_at":"2023-11-16T19:56:05.453Z","dependency_job_id":"b37202cc-82f7-4c0c-8d14-a5aedae6e65d","html_url":"https://github.com/AntonioFalcaoJr/EventualShop","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AntonioFalcaoJr%2FEventualShop","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AntonioFalcaoJr%2FEventualShop/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AntonioFalcaoJr%2FEventualShop/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AntonioFalcaoJr%2FEventualShop/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/AntonioFalcaoJr","download_url":"https://codeload.github.com/AntonioFalcaoJr/EventualShop/tar.gz/refs/heads/release","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246880169,"owners_count":20848819,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["architecture","clean-architecture","cqrs","ddd","ddd-architecture","domain-driven-design","dotnet","dotnet6","dotnet7","eda","event-driven","event-sourcing","event-store","eventsourcing","eventstore","masstransit","microservices","reactive","reactive-programming","uncertainty"],"created_at":"2024-08-01T12:00:49.098Z","updated_at":"2025-04-02T19:32:15.362Z","avatar_url":"https://github.com/AntonioFalcaoJr.png","language":"C#","funding_links":[],"categories":["Examples"],"sub_categories":[],"readme":"# ![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/new_logo.png)\n\n\u003cp align=\"center\"\u003e\n \u003ca href=\"#bulb-about\"\u003eAbout\u003c/a\u003e \u0026nbsp;\u0026bull;\u0026nbsp;\n \u003ca href=\"#classical_building-the-solution-architecture\"\u003eThe Solution Architecture\u003c/a\u003e \u0026nbsp;\u0026bull;\u0026nbsp;\n \u003ca href=\"#mag_right-research\"\u003eResearch\u003c/a\u003e \u0026nbsp;\u0026bull;\u0026nbsp;\n \u003ca href=\"#computer-running\"\u003eRunning\u003c/a\u003e \u0026nbsp;\u0026bull;\u0026nbsp;\n \u003ca href=\"#toolbox-tech-stack\"\u003eTech Stack\u003c/a\u003e\n\u003c/p\u003e\n\n\u003cbr\u003e\n\n\u003cdiv align=\"center\"\u003e\n\n| Service | Command Stack | Query Stack | \n|---------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|\n| Account | [![Account - Command Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/account-command.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/account-command.yaml) | [![Account - Query Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/account-query.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/account-query.yaml) |\n| Communication | [![Communication - Command Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/communication-command.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/communication-command.yaml) | [![Communication - Query Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/communication-query.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/communication-query.yaml) |\n| Identity | [![Identity - Command Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/identity-command.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/identity-command.yaml) | [![Identity - Query Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/identity-query.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/identity-query.yaml) |\n| Order | [![Order - Command Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/order-command.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/order-command.yaml) | [![Order - Query Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/order-query.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/order-query.yaml) |\n| Catalog | [![Catalog - Command Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/catalog-command.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/catalog-command.yaml) | [![Catalog - Query Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/catalog-query.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/catalog-query.yaml) |\n| Warehouse | [![Warehouse - Command Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/warehouse-command.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/warehouse-command.yaml) | [![Warehouse - Query Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/warehouse-query.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/warehouse-query.yaml) |\n| Shopping Cart | [![Shopping Cart - Command Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/shopping-cart-command.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/shopping-cart-command.yaml) | [![Shopping Cart - Query Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/shopping-cart-query.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/shopping-cart-query.yaml) |\n| Payment | [![Payment - Command Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/payment-command.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/payment-command.yaml) | [![Payment - Query Stack](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/payment-query.yaml/badge.svg)](https://github.com/AntonioFalcaoJr/EventualShop/actions/workflows/payment-query.yaml) |\n\n :construction: \u003csub\u003eWork in Progress (WIP)\u003c/sub\u003e\n\n\u003c/div\u003e\n \n## :bulb: About\n\nThe main objective of this **cloud-native** project is to represent the state-of-the-art of a **distributed**, **reliable**, and **highly scalable** system by interpreting the most relevant principles of [**Reactive\nDomain Driven Design**](https://www.infoq.com/articles/modeling-uncertainty-reactive-ddd/).\n\n\u003e Domain-Driven Design can aid with managing uncertainty through the use of good modeling. \n\u003e -- Vaughn Vernon\n\n**Scalability** and **Resilience** require **low coupling** and **high cohesion**, principles strongly linked to the proper understanding of the business through **well-defined boundaries**, combined with a healthy and\nefficient integration strategy such as **Event-driven Architecture** (EDA).\n\nThe [**Event Storming**](https://www.eventstorming.com/) workshop provides a practical approach to **subdomain decomposition**, using **Pivotal Events** to correlate business capabilities across **Bounded Contexts** while promoting **reactive\nintegration** between Aggregates.\n\nThe **reactive** integration between **Bounded Contexts** configures an **Event-driven Architecture** (EDA) where **Commands** are acknowledged and sent to the Bus by the Web API (BFF/Gateway) while **Events** are\nbroadcasted to the **Query** side and/or other Aggregates.\n\n**Independence**, as the main characteristic of a **Microservice**, can only be found in a **Bounded Context**.\n\nThe [**Event Sourcing**](https://www.eventstore.com/event-sourcing) is a proprietary implementation that, in addition to being **naturally auditable** and **data-driven**, represents the most efficient persistence mechanism ever. An **eventual state\ntransition** Aggregate design is essential at this point. The **Event Store** comprises EF Core (ORM) + MSSQL (Database).\n\n\u003e State transitions are an important part of our problem space and should be modeled within our domain. \n\u003e -- Greg Young\n\n[**Projections**](https://www.eventstore.com/event-sourcing#Projections) are **asynchronously denormalized** and stored on a NoSQL Database(MongoDB); Nested documents should be avoided here; Each projection has its index and **fits perfectly into a view or component**,\nmitigating unnecessary data traffic and making the reading side as efficient as possible.\n\nThe splitting between **Command** and **Query** stacks occurs logically through the [**CQRS**](https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf) pattern and fiscally via a **Microservices** architecture. Each stack is an individual deployable unit with its database,\nand the data flows from Command to Query stack via **Domain** and/or **Summary** events.\n\nAs a **domain-centric** approach, [**Clean Architecture**](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html) provides the appropriate isolation between the **Core** (Application + Domain) and \"times many\" **Infrastructure** concerns.\n\n### :star: Give a Star! \n\nSupport this research by **giving it a star**. Thanks!\n\n## :classical_building: The Solution Architecture\n\n### V2\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/solution_architecture_v2.png) \n\n### V1\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/solution_architecture_v1.png)\n\n## :mag_right: Research\n\n\u003cdetails\u003e\n \u003csummary\u003e Agnostic Obsession \u003c/summary\u003e\n\n### Agnostic Obsession\n\nAgnostic obsession is a design approach that focuses on creating software unrelated to any specific domain, application, or technology. Some strategies adopted in this project are related to particular principles, such as the **domain-centric** to support the business (**Reactive DDD** and **Clean Architecture**); **Event Sourcing** + **object-relational mapping** (ORM) for persistence mechanism; **Containers** for immutable environments; and **Kubernetes** (K8s) for cloud deployment.\n\nThe **domain-centric** approach is a design pattern that separates the core business logic of an application from other concerns, such as the user interface or infrastructure, making it easier to maintain and extend the application, as the core domain is isolated from other system components. Additionally, the ability to move the core domain to different applications while **keeping the essence of the business** can be helpful for organizations that need to support multiple applications or platforms.\n\nA key aspect of agnostic obsession is **event-sourcing** and **object-relational mapping** (ORM) as a persistence mechanism. Event sourcing involves storing the history of events occurring within a system rather than the system's current state, **avoiding advanced database capabilities such as Joins, Triggers, Procedures, and more**. On the other hand, ORM is a technique that maps objects in a program to data stored in a database, making it easier and more abstract to manage data.\n\nAnother essential aspect of agnostic obsession is using **containers to create immutable environments**. Containers are a lightweight virtualization form that allows packaging an application and its dependencies into a single, self-contained unit, making it easy to deploy and run the application in any environment without worrying about the underlying infrastructure or platform.\n\nFinally, agnostic obsession often involves using **Kubernetes** (K8s) for cloud deployment. K8s is an open-source platform for managing and deploying containerized applications. It is widely used in the industry and supported by most cloud providers, making it a natural choice for agnostic obsession.\n\nIn summary, agnostic obsession is a powerful approach that allows for creating highly flexible and adaptable software that can be easily moved and deployed in different environments. Using event-sourcing, ORM, Containers, and K8s, it is possible to build resilient, scalable, and easy-to-maintain systems.\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003e Reactive Domain Driven Design \u003c/summary\u003e\n\n### Reactive Domain Driven Design\n\nReactive DDD aims to create software that is responsive, resilient, and scalable, by applying the principles of reactive programming to domain-driven design. This involves using asynchronous and\nnon-blocking communication between the different components of the system, and using events and streams to model the domain concepts and relationships.\n\n\u003e I have been seeing, at least in my world, a trend towards reactive systems. Not just reactive within a microservice, but building entire systems that are reactive. In DDD, reactive behavior is also\n\u003e happening within the bounded context. Being reactive isn't entirely new, and Eric Evans was far ahead of the industry when he introduced eventing. Using domain events means we have to react to\n\u003e events that happened in the past, and bring our system into harmony.\n\u003e\n\u003e [Vernon, Vaughn. \"Modeling Uncertainty with Reactive DDD\", _www.infoq.com_, last edited on 29 Set 2018](https://www.infoq.com/articles/modeling-uncertainty-reactive-ddd/)\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/reactive-system.jpg) \n[Fig. 2: Vernon, V. (2018), \"Modeling Uncertainty with Reactive DDD\", _Reactive Systems_, www.infoq.com](https://www.infoq.com/articles/modeling-uncertainty-reactive-ddd/)\n\n### Reactive Process\n\n\u003e Each domain entity is responsible for tracking its state, based on the commands it receives. By following good DDD practices, the state can be safely tracked based on these commands, and using event\n\u003e sourcing to persist the state change events.\n\u003e\n\u003e This is where we want to be. When everything is happening asynchronously everywhere, what happens? That brings us to uncertainty.\n\u003e\n\u003e If there is any possibility of any message being out of order, you have to plan for all of them being out of order.\n\u003e\n\u003e Each entity is also responsible for knowing how to handle any potential uncertainty, according to decisions made by domain experts. For example, if a duplicate event is received, the aggregate will\n\u003e know that it has already seen it, and can decide how to respond.\n\u003e\n\u003e [Vernon, Vaughn. \"Modeling Uncertainty with Reactive DDD\", _www.infoq.com_, last edited on 29 Set 2018](https://www.infoq.com/articles/modeling-uncertainty-reactive-ddd/)\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/reactive_process.jpg) \n[Fig. 3: Vernon, V. (2018), \"Modeling Uncertainty with Reactive DDD\", _Process Manager_, www.infoq.com](https://www.infoq.com/articles/modeling-uncertainty-reactive-ddd/)\n\n### Messaging - Making good use of Context Mapping\n\n\u003e When using asynchronous messaging to integrate, much can be accomplished by a client Bounded Context subscribing to the Domain Events published by your own or another Bounded Context. Using\n\u003e messaging is one of the most robust forms of integration because you remove much of the temporal coupling associated with blocking forms such as RPC and REST. Since you already anticipate the\n\u003e latency of message exchange, you tend to build more robust systems because you never expect immediate results.\n\u003e\n\u003e Typically an Aggregate in one Bounded Context publishes a Domain Event, which could be consumed by any number of interested parties. When a subscribing Bounded Context receives the Domain Event,\n\u003e some action will be taken based on its type and value. Normally it will cause a new Aggregate to be created or an existing Aggregate to be modified in the consuming Bounded Context.\n\u003e\n\u003e Vernon, V. (2016) Domain-Driven Design Distilled, 1st ed. New York: Addison-Wesley Professional, p65-67.\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/messaging_context_mapping.png) \nFig. 4: Vernon, V. (2016), Messaging from Domain-Driven Design Distilled, 1st ed, p65.\n\n### Domain Driven Design (DDD)\n\n\u003e Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. The name\n\u003e comes from a 2003 book by Eric Evans that describes the approach through a catalog of patterns. Since then a community of practitioners have further developed the ideas, spawning various other books\n\u003e and training courses. The approach is particularly suited to complex domains, where a lot of often-messy logic needs to be organized.\n\u003e\n\u003e [Fowler, Martin. \"DomainDrivenDesign\", _martinfowler.com_, last edited on 22 April 2020](https://martinfowler.com/bliki/DomainDrivenDesign.html)\n\n#### Bounded Context\n\n\u003e Basically, the idea behind bounded context is to put a clear delineation between one model and another model. This delineation and boundary that's put around a domain model, makes the model that is\n\u003e inside the boundary very explicit with very clear meaning as to the concepts, the elements of the model, and the way that the team, including domain experts, think about the model.\n\u003e\n\u003e You'll find a ubiquitous language that is spoken by the team and that is modeled in software by the team. In scenarios and discussions where somebody says, for example, \"product,\" they know in that\n\u003e context exactly what product means. In another context, product can have a different meaning, one that was defined by another team. The product may share identities across bounded contexts, but,\n\u003e generally speaking, the product in another context has at least a slightly different meaning, and possibly even a vastly different meaning.\n\u003e\n\u003e [Vernon, Vaughn. \"Modeling Uncertainty with Reactive DDD\", _www.infoq.com_, last edited on 29 Set 2018](https://martinfowler.com/bliki/BoundedContext.html)\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/BoundedContext.jpg) \n[Fig. 5: Martin, Fowler. _BoundedContext_](https://martinfowler.com/bliki/BoundedContext.html)\n\n\u003e First, a Bounded Context is a semantic contextual boundary. This means that within the boundary each component of the software model has a specific meaning and does specific things. The components\n\u003e inside a Bounded Context are context specific and semantically motivated. That’s simple enough.\n\u003e\n\u003e When you are just getting started in your software modeling efforts, your Bounded Context is somewhat conceptual. You could think of it as part of your problem space. However, as your model starts\n\u003e to take on deeper meaning and clarity, your Bounded Context will quickly transition to your solution space , with your software model being reflected as project source code. Remember that a Bounded\n\u003e Context is where a model is implemented, and you will have separate software artifacts for each Bounded Context.\n\u003e\n\u003e Vernon, V. (2016). \"Strategic Design with Bounded Contexts and the Ubiquitous Language\", Domain-Driven Design Distilled, 1st ed. New York: Addison-Wesley Professional.\n\n\u003e Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such\n\u003e as code bases and database schemas. Apply Continuous Integration to keep model concepts and terms strictly consistent within these bounds, but don’t be distracted or confused by issues outside.\n\u003e Standardize a single development process within the context, which need not be used elsewhere.\n\u003e\n\u003e [Evans, Eric. (2015). \"Bounded Context\", Domain-Driven Design Reference](https://www.domainlanguage.com/ddd/reference)\n\n#### Aggregate\n\n\u003e I think a model is a set of related concepts that can be applied to solve a problem.\n\u003e -- \u003ccite\u003e Eric Evans \u003c/cite\u003e\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/aggregate.png) \nFig. 6: Vernon, V. (2016), Aggregates from Domain-Driven Design Distilled, 1st ed, p78.\n\n\u003e Each Aggregate forms a transactional consistency boundary. This means that within a single Aggregate, all composed parts must be consistent, according to business rules, when the controlling\n\u003e transaction is committed to the database. This doesn't necessarily mean that you are not supposed to compose other elements within an Aggregate that don't need to be consistent after a transaction.\n\u003e After all, an Aggregate also models a conceptual whole. But you should be first and foremost concerned with transactional consistency. The outer boundary drawn around Aggregate Type 1 and Aggregate\n\u003e Type 2 represents a separate transaction that will be in control of atomically persisting each object cluster.\n\u003e\n\u003e Vernon, V. (2016) Domain-Driven Design Distilled, 1st ed. New York: Addison-Wesley Professional, p78.\n\n\u003e Aggregate is a pattern in Domain-Driven Design. A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be\n\u003e separate objects, but it's useful to treat the order (together with its line items) as a single aggregate.\n\u003e\n\u003e [Fowler, Martin. \"DDD_Aggregate\", _martinfowler.com_, last edited on 08 Jun 2015](https://martinfowler.com/bliki/DomainDrivenDesign.html)\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003e Event Sourcing \u003c/summary\u003e\n\n### Event Sourcing\n\nNote. _Greg Young takes the next steps beyond the DDD principles and best practices introduced by Eric Evans in **Domain-Driven Design: Tackling Complexity in the Heart of Software**, using DDD\nwith **Command-Query Responsibility Segregation** (CQRS) and **event sourcing** to simplify construction, decentralize decision-making, and make system development more flexible and responsive._\nAdapted from \"Event Centric: Finding Simplicity in Complex Systems\" by Y. Greg, 2012.\n\n\u003e Instead of storing just the current state of the data in a domain, use an append-only store to record the full series of actions taken on that data. The store acts as the system of record and can be\n\u003e used to materialize the domain objects. This can simplify tasks in complex domains, by avoiding the need to synchronize the data model and the business domain, while improving performance,\n\u003e scalability, and responsiveness. It can also provide consistency for transactional data, and maintain full audit trails and history that can enable compensating actions.\n\u003e\n\u003e [\"Event Sourcing pattern\" _MSDN_, Microsoft Docs, last edited on 23 Jun 2017](https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing)\n\n\u003e We can query an application's state to find out the current state of the world, and this answers many questions. However there are times when we don't just want to see where we are, we also want to\n\u003e know how we got there.\n\u003e\n\u003e Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not just can we query these events, we can also use the event log to reconstruct past states, and as\n\u003e a foundation to automatically adjust the state to cope with retroactive changes.\n\u003e\n\u003e [Fowler, Martin. \"Eventsourcing\", _martinfowler.com_, last edited on 12 Dec 2005](https://martinfowler.com/eaaDev/EventSourcing.html)\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/event-sourcing-overview.png) \n[Fig. 7: MSDN. _Event Sourcing pattern_](https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing#solution)\n\n### Updating entities\n\n\u003e To update an entity’s state we use commands from the outside and events on the inside:\n\u003e\n\u003e - Commands: The state of the entity can be changed only by sending commands to it. The commands are the \"external\" API of an entity. Commands request state changes. The current state may reject the\n\u003e command, or it may accept it producing zero, one or many events (depending on the command and the current state).\n\u003e\n\u003e\n\u003e - Events: The events represent changes of the entity’s state and are the only way to change it. The entity creates events from commands. Events are an internal mechanism for the entity to mutate the\n\u003e state, other parties can’t send events. Other parts of the application may listen to the created events. Summing up, events are facts.\n\u003e\n\u003e The events are persisted to the datastore, while the entity state is kept in memory. In case of a restart the latest state gets rebuilt by replaying the events from the Event Journal.\n\u003e\n\u003e [\"Event Sourcing\" _Akka platform_, developer.lightbend.com](https://developer.lightbend.com/docs/akka-platform-guide/concepts/event-sourcing.html)\n\n### Pattern\n\n\u003e _want to learn event sourcing?_ \n\u003e _f(state, event) =\u003e state_\n\u003e\n\u003e -- \u003ccite\u003e@gregyoung\u003c/cite\u003e\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/event-sourcing-state-transition.png) \n[Fig. 8: Battermann, Leif. _12 Things You Should Know About Event Sourcing_](http://blog.leifbattermann.de/2017/04/21/12-things-you-should-know-about-event-sourcing)\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/eventsourcingrequestflow.png) \n[Fig. 9: Eventuate. _Event Sourcing_](https://eventuate.io/whyeventsourcing.html)\n\nThe mantra of event sourcing and cover the four steps in slightly more details:\n\n 1 - A command is received by an aggregate.\n \n 2 - The aggregate checks to see if the command can be applied.\n \n 3 - If the command can be applied:\n \n 1 - The aggregate creates at least one event;\n 2 - The aggregate changes state based on the event details;\n 3 - As a unit: \n 3.1 - The event is persisted in the store;\n 3.2 - The event is published in the exchange.\n \n 4 - If the command cannot be applied:\n \n 1 - If necessary, the aggregate creates a failure event;\n 2 - The aggregate changes state based on the failure event;\n 3 - As a unit: \n 3.1 - The failure event is persisted in the store;\n 3.2 - The failure event is published in the exchange.\n\nState transition during events applying:\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/applyTo_event-sourcing.png) \n[Fig. 10: Reitzammer, Benjamin \u0026 Seitz, Johannes. _Event Sourcingin practice_](https://ookami86.github.io/event-sourcing-in-practice/#making-eventsourcing-work/18-concurrent-modifictations.md)\n\n### Event Store\n\n\u003e So, Event Sourcing is the persistence mechanism where each state transition for a given entity is represented as a domain event that gets persisted to an event database (event store). When the\n\u003e entity state mutates, a new event is produced and saved. When we need to restore the entity state, we read all the events for that entity and apply each event to change the state, reaching the\n\u003e correct final state of the entity when all available events are read and applied.\n\u003e\n\u003e [Zimarev, Alexey. \"What is Event Sourcing?\", _Event Store blog_, last edited on 03 June 2020](https://www.eventstore.com/blog/what-is-event-sourcing)\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/event-store.png) \n[Fig. 11: Shilkov, Mikhail. _Event Sourcing and IO Complexity_](https://mikhail.io/2016/11/event-sourcing-and-io-complexity)\n\nThe following picture shows the difference between approaches:\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/event-sourcing.png)\n[Fig. 12: Richardson, Chris. _Pattern: Event sourcing_](https://microservices.io/patterns/data/event-sourcing.html)\n\n#### Exemplifying\n\n##### Store Event\n\n```sql\nCREATE TABLE [Events] (\n [Version] bigint NOT NULL,\n [AggregateId] uniqueidentifier NOT NULL,\n [AggregateName] varchar(30) NOT NULL,\n [DomainEventName] varchar(50) NOT NULL,\n [DomainEvent] nvarchar(max) NOT NULL,\n CONSTRAINT [PK_Events] PRIMARY KEY ([Version], [AggregateId])\n);\n```\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/store-event.png)\n\n```json\n{\n \"$type\": \"Contracts.Services.Account.DomainEvent+AccountCreated, Contracts\",\n \"Id\": \"b7450a4c-5749-4131-830c-28dcfd7e5dea\",\n \"FirstName\": \"Antônio Roque\",\n \"LastName\": \"Falcão Júnior\",\n \"Email\": \"arfj@edu.univali.br\",\n \"Timestamp\": \"2022-08-31T19:27:41.7810008-03:00\",\n \"CorrelationId\": \"b7450a4c-5749-4131-830c-28dcfd7e5dea\"\n}\n```\n\n##### Snapshot\n\n```sql\nCREATE TABLE [Snapshots] (\n [AggregateVersion] bigint NOT NULL,\n [AggregateId] uniqueidentifier NOT NULL,\n [AggregateName] varchar(30) NOT NULL,\n [AggregateState] nvarchar(max) NOT NULL,\n CONSTRAINT [PK_Snapshots] PRIMARY KEY ([AggregateVersion], [AggregateId])\n);\n```\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/store-snapshot.png)\n\n```json\n{\n \"CustomerId\": \"3fa85f64-5717-4562-b3fc-2c963f66afa6\",\n \"Status\": {\n \"Name\": \"Confirmed\",\n \"Value\": 2\n },\n \"BillingAddress\": null,\n \"ShippingAddress\": null,\n \"Total\": 0.0,\n \"TotalPayment\": 0.0,\n \"AmountDue\": 0.0,\n \"Items\": [],\n \"PaymentMethods\": [],\n \"Id\": \"de2ec981-24c1-4c27-abbb-dd50d99a1e16\",\n \"IsDeleted\": false\n}\n```\n### Snapshot\n\n\u003e Once you understand how Event Sourcing works, the most common thought is: “What happens when you have a lot of Events? Won’t it be inefficient to fetch every event from the event stream and replay\n\u003e all of them to get to the current state?”. It might be. But to combat this, you can use snapshots in event sourcing to rehydrate aggregates. Snapshots give you a representation of your aggregates\n\u003e state at a point in time. You can then use this as a checkpoint and then only replay the events since the snapshot.\n\u003e\n\u003e [Comartin, Derek. \"Snapshots in Event Sourcing for Rehydrating Aggregates\", _codeopinion.com_, last edited on 17 Mar 2021](https://codeopinion.com/snapshots-in-event-sourcing-for-rehydrating-aggregates)\n\n\u003e Snapshotting is an optimisation that reduces time spent on reading event from an event store. If for example a stream contains thousands of events, and we need to read all of them every time, then\n\u003e the time the system takes to handle a command will be noticeable. What we can do instead is to create a snapshot of the aggregate state and save it. Then before a command is handled we can load the\n\u003e latest snapshot and only new events since the snapshot was created.\n\u003e\n\u003e [Gunia, Kacper. \"Event Sourcing: Snapshotting\", _domaincentric.net_, last edited on 5 Jun 2020](https://domaincentric.net/blog/event-sourcing-snapshotting)\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/snapshot.png) \n[Fig. 13: Comartin, Derek. _Snapshots in Event Sourcing for Rehydrating Aggregates_](https://codeopinion.com/snapshots-in-event-sourcing-for-rehydrating-aggregates)\n\nSnapshot stream:\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/stream_snapshot.png) \n[Fig. 14: Comartin, Derek. _Snapshots in Event Sourcing for Rehydrating Aggregates_](https://codeopinion.com/snapshots-in-event-sourcing-for-rehydrating-aggregates)\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003eEvent-Driven Architecture (EDA)\u003c/summary\u003e\n\n### Event-Driven Architecture (EDA)\n\n\u003e Event-driven architecture (EDA) is a software architecture paradigm promoting the production, detection, consumption of, and reaction to events. An event can be defined as \"a significant change in\n\u003e state\".\n\u003e\n\u003e [\"Event-driven architecture.\" _Wikipedia_, Wikimedia Foundation, last edited on 9 May 2021](https://en.wikipedia.org/wiki/Event-driven_architecture)\n\n\u003e Event-driven architecture refers to a system of loosely coupled microservices that exchange information between each other through the production and consumption of events. An event-driven system\n\u003e enables messages to be ingested into the event driven ecosystem and then broadcast out to whichever services are interested in receiving them.\n\u003e\n\u003e [Jansen, Grace \u0026 Saladas, Johanna. \"Advantages of the event-driven architecture pattern.\" _developer.ibm.com_, IBM Developer, last edited on 12 May 2021](https://developer.ibm.com/articles/advantages-of-an-event-driven-architecture)\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/eda.png) \n[Fig. 15: Uit de Bos, Oskar. _A simple illustration of events using the publish/subscribe messagingmodel_](https://medium.com/swlh/the-engineers-guide-to-event-driven-architectures-benefits-and-challenges-3e96ded8568b)\n\n### Topologies\n\n\u003e To achieve complex responses, event-driven architectures consist of two main topologies: the mediator and the broker. The mediator topology is commonly used when you need to orchestrate multiple\n\u003e steps within an event through a central mediator, whereas the broker topology is used when you want to chain events and responses together directly without the need for a mediator. Because the\n\u003e architecture characteristics and implementation strategies differ between these two EDA topologies, it is important to understand each one to know which is best suited for your particular use case.\n\u003e\n\u003e [\"Event-Driven Architecture Topologies – Broker and Mediator.\" _www.3pillarglobal.com_, last edited on 20 Set 2021](https://www.3pillarglobal.com/insights/event-driven-architecture-topologies-broker-and-mediator/)\n\n#### Broker Topology\n\n\u003e The broker topology differs from the mediator topology in that there is no central event mediator; rather, the message flow is distributed across the event processor components in a chain-like\n\u003e fashion through a lightweight message broker (e.g., ActiveMQ, HornetQ, etc.). This topology is useful when you have a relatively simple event processing flow and you do not want (or need) central\n\u003e event orchestration.\n\u003e\n\u003e There are two main types of architecture components within the broker topology: a broker component and an event processor component. The broker component can be centralized or federated and contains\n\u003e all of the event channels that are used within the event flow. The event channels contained within the broker component can be message queues, message topics, or a combination of both.\n\u003e\n\u003e [Richards, Mark. \"Broker Topology.\" _Software Architecture Patterns by Mark Richards_, O'Reilly](https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch02.html)\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/broker_topology_eda.png) \n[Fig. 16: Richards, Mark. \"Broker Topology.\" _Software Architecture Patterns by Mark Richards_, O'Reilly](https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch02.html)\n\n#### Choreography-based SAGA\n\n\u003e In a choreography-based saga, the saga participants collaborate by exchanging events. Each step of a choreography-based saga updates the database (e.g. an aggregate) and publishes a domain event.\n\u003e The first step of a saga is initiated by a command that’s invoked by an external request, such an HTTP POST. Each subsequent step is triggered by an event emitted by a previous step.\n\u003e\n\u003e [Richardson, Chris. \"Implementing a choreography-based saga.\" _Managing data consistency in a microservice architecture using Sagas_, chrisrichardson.net](https://chrisrichardson.net/post/sagas/2019/08/15/developing-sagas-part-3.html#:%7E:text=In%20a%20choreography%2Dbased%20saga,and%20publishes%20a%20domain%20event.\u0026text=The%20step%20of%20the%20saga,data%20and%20emits%20an%20event)\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/Saga.png) \n[Fig. 17: Richardson, Chris. \"Implementing a choreography-based saga.\" _Managing data consistency in a microservice architecture using Sagas_, chrisrichardson.net](https://chrisrichardson.net/post/sagas/2019/08/15/developing-sagas-part-3.html#:%7E:text=In%20a%20choreography%2Dbased%20saga,and%20publishes%20a%20domain%20event.\u0026text=The%20step%20of%20the%20saga,data%20and%20emits%20an%20event)\n\n#### Orchestration vs Choreography\n\n_SAGA - A long story about past events over a long period of time._\n\n\u003e Orchestration entails actively controlling all elements and interactions like a conductor directs the musicians of an orchestra, while choreography entails establishing a pattern or routine that\n\u003e microservices follow as the music plays, without requiring supervision and instructions.\n\u003e\n\u003e [Schabowsky, Jonathan. \"The Benefits of Choreography\", _solace.com_, last edited on 16 Nov 2019](https://solace.com/blog/microservices-choreography-vs-orchestration)\n\n#### Orchestration\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/orchestration.png) \nFig. 18: Falcão, Antônio. \"Order orchestration-based saga\".\n\nBenefits \u0026 drawbacks of Orchestration\n\n- Centralized logic: this can be good and bad;\n- High coupling: Need to know about the capability of other services;\n- Easier to understand the workflow since its defined in a central location;\n- Full control over the workflow steps via commands;\n- Point of failure;\n- Easier to debug and test.\n\n#### Choreography\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/choreography.png) \nFig. 19: Falcão, Antônio. \"Order choreography-based saga\".\n\nBenefits \u0026 drawbacks of Choreography\n\n- No centralized logic: this can be good and bad;\n- Low coupling: Clear separation of concerns;\n- Better performance: Fewer messages to handle;\n- Useful for small/simple workflows;\n- Difficult to conceptualize if a lot of services are involved;\n- Harder to debug \u0026 test if a lot of services are involved.\n\n### EDA \u0026 Microservices Architecture\n\nThe following table shows how EDA and Microservices architectural styles compliment each other:\n\n| EDA | Microservices Architecture |\n|-----------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------|\n| Loose coupling between components/services | Bounded context which provides separation of concerns |\n| Ability to scale individual components | Independently deployable \u0026 scalable |\n| Processing components can be developed independent of each other | Support for polyglot programming |\n| High cloud affinity | Cloud native |\n| Asynchronous nature. As well as ability to throttle workload | Elastic scalability |\n| Fault Tolerance and better resiliency | Good observability to detect failures quickly |\n| Ability to build processing pipelines | Evolutionary in nature |\n| Availability of sophisticated event brokers reduce code complexity | Set of standard reusable technical services often referred as `MicroServices Chassis` |\n| A rich palate of proven [Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/) | Provides a rich repository of reusable [implementation patterns](https://microservices.io/patterns/microservices.html) |\n\n[Table 1: Ambre, Tanmay. _Architectural styles compliment_, Architectural considerations for event-driven microservices-based systems](https://developer.ibm.com/articles/eda-and-microservices-architecture-best-practices)\n\n### EDA vs SOA\n\n\u003e Compared to SOA, the essence of an EDA is that the services involved communicate through the capture, propagation, processing and persistence of events. This resulting pattern of communicating\n\u003e through a dataflow is quite different from the SOA approach of requests and responses.\n\u003e\n\u003e [Mathew, Jerry. \"SOA vs. EDA: Is Not Life Simply a Series of Events?.\" _Confluent.io_, last edited on 19 Mar 2019](https://www.confluent.io/blog/soa-vs-eda-is-not-life-simply-a-series-of-events)\n\nAccording to Mathew, here are some reasons why the EDA patterns can alleviate some of the challenges traditional SOA patterns bring:\n\n| | SOA | EDA |\n|--------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Pull vs. Reactive | Client makes a request of a service and expects a response. It’s great for persisted, static data, but gets a little hard when data keeps changing. You have to poll to detect changes. | Subscription model pushes events to consumers. |\n| Coupling | Client has to know details of the API and its location at runtime. | Producers have no knowledge of consumer which will ultimately receive the event. There is still some minimal coupling in terms names of queues/topics and event formats. |\n| Service Availability | A service must be available at the time a request is made by a client even if you are doing an asynchronous response handling. | Events do not require a reply and are inherently asynchronous. Events can be persisted for future consumption. With a highly fault-tolerant broker, the event producer does not need to know whether the consumers are available. Thus, we achieve higher resilience to network and compute failure, and this allows event producers to avoid blocking. |\n| Process Modification and Extension | Processing logic is a request-response API that is hardwired into a service endpoint (with or without service discovery). If the logic needs to change or be extended, or if new logic needs to be introduced, the definition (not contract) of the service must be updated. This introduces change management and regression risk. | Additional event producers and consumers can be added to a system without any explicit process definition. |\n| Consistency Between Process Interaction and Internal State Management | State changes are managed based on requests. For example, a request to “withdraw money” mutates the state of an account. The distinct processes of a request, a change in state and its persistence in case of failure must be tied together transactionally. This often leads users to deploy expensive distributed transaction protocols like eXtended architecture (XA). | EDA provides better support for consistency between process interaction and persisted internal state transitions. This is done through the event sourcing pattern, where the communication protocol (the event) is also the persistence mechanism (the event log). The current state of a system can be built or rebuilt from the log of events. |\n| Retaining the Exact State Transitions That Customers or Services Perform | In SOAs, data is typically “mutated in place” in a database. This is a lossy process where each state change loses the information about the state changes that happened previously. | EDAs are event sourced, meaning every state change is captured, providing a truthful journal of the exact state changes that every customer or every service made over time. This journal lets operators rewind time to view or replay previous events exactly as they happened. It is also important for analytics that review customer (or system) behavior to derive insight. |\n| *Streaming Analytics | SOA is incapable of deriving analytics of data in flight. This requires the ability to detect a pattern from multiple state changes both temporally and spatially. | EDA is fully capable of detecting patterns across multiple event sources over many different types of time windows. Also, deriving analytics of data in flight is a means of continuous intelligence. |\n| The Timing of Consistency and of Intelligence | Synchronous communication makes it a bit easier to create consistent state across services from a client’s perspective. Intelligence from the consistent state are derived eventually—that is, eventual intelligence and continuous consistency | Events, being asynchronous, mean that different services become consistent with one another only in eventuality: There is no control over the timeliness of the process of event propagation. |\n\n[Table 2: Mathew, Jerry. _SOA vs. EDA: Is Not Life Simply a Series of Events?_](https://www.confluent.io/blog/soa-vs-eda-is-not-life-simply-a-series-of-events)\n\n### EDA \u0026 Event-sourcing\n\n\u003e Event sourcing a system means the treatment of events as the source of truth. In principle, until an event is made durable within the system, it cannot be processed any further. Just like an\n\u003e author’s story is not a story at all until it’s written, an event should not be projected, replayed, published or otherwise processed until it’s durable enough such as being persisted to a data\n\u003e store. Other designs where the event is secondary cannot rightfully claim to be event sourced but instead merely an event-logging system.\n\u003e\n\u003e Combining EDA with the event-sourcing pattern is another increment of the system’s design because of the alignment of the EDA principle that events are the units of change and the event-sourcing\n\u003e principle that events should be stored first and foremost.\n\u003e\n\u003e [Go, Jayson. \"From Monolith to Event-Driven: Finding Seams in Your Future Architecture\", _InfoQ_, last edited on 15 Set 2020](https://www.eventstore.com/blog/what-is-event-sourcing)\n\nComparison overview:\n\n| Aspects | Event sourcing | EDA |\n|---------|---------------------------|---------------------------------|\n| Propose | Keeping history | Highly adaptable and scalable |\n| Scope | Single application/system | Whole organisation/several apps |\n| Storage | Central event store | Decentralised |\n| Testing | Easier | Harder |\n\n[Table 3: Lorio, Pablo. _Comparison overview_, Event driven architectures vs event sourcing patterns](https://pablo-iorio.medium.com/event-driven-architectures-vs-event-sourcing-patterns-23d328289bf9)\n\n\u003cbr\u003e\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/EventSourcing_EDA.jpeg) \n[Fig. 20: Nowak, Aleksander. _Understanding Event-Driven Design Patterns for Microservices_](https://levelup.gitconnected.com/understanding-event-driven-design-patterns-for-microservices-659b3c9fb51f)\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003eMicroservices\u003c/summary\u003e\n\n### Microservices\n\n\u003e The term \"Microservice Architecture\" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there\n\u003e is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints,\n\u003e and decentralized control of languages and data.\n\u003e\n\u003e [Fowler, Martin. \"Microservices\", _martinfowler.com_, last edited on 25 Mar 2014](https://martinfowler.com/articles/microservices.html)\n\n#### Temporal Coupling and Autonomous Decisions\n\n\u003e Temporal coupling is where you have a dependency on time where one service or one component cannot complete its operation until the other party is done with work. In order to get rid of this\n\u003e temporal coupling, what you can do is you can use events.\n\u003e\n\u003e [Alagarsamy, Indu. \"Practical DDD: Bounded Contexts + Events =\u003e Microservices\", _www.infoq.com_, last edited on 03 Set 2019](https://www.infoq.com/presentations/microservices-ddd-bounded-contexts)\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003eCQRS\u003c/summary\u003e\n\n### CQRS\n\n\u003e CQRS stands for Command and Query Responsibility Segregation, a pattern that separates read and update operations for a data store. Implementing CQRS in your application can maximize its\n\u003e performance, scalability, and security. The flexibility created by migrating to CQRS allows a system to better evolve over time and prevents update commands from causing merge conflicts at the\n\u003e domain level.\n\u003e\n\u003e Benefits of CQRS include:\n\u003e\n\u003e - **Independent scaling**. CQRS allows the read and write workloads to scale independently, and may result in fewer lock contentions.\n\u003e - **Optimized data schemas**. The read side can use a schema that is optimized for queries, while the write side uses a schema that is optimized for updates.\n\u003e - **Security**. It's easier to ensure that only the right domain entities are performing writes on the data.\n\u003e - **Separation of concerns**. Segregating the read and write sides can result in models that are more maintainable and flexible. Most of the complex business logic goes into the write model. The\n \u003e read model can be relatively simple.\n\u003e - **Simpler queries**. By storing a materialized view in the read database, the application can avoid complex joins when querying.\n\u003e\n\u003e [\"What is the CQRS pattern?\" _MSDN_, Microsoft Docs, last edited on 2 Nov 2020](https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs)\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/cqrs.png) \n[Fig. 21: Bürckel, Marco. _Some thoughts on using CQRS without Event Sourcing_](https://medium.com/@mbue/some-thoughts-on-using-cqrs-without-event-sourcing-938b878166a2)\n\n\u003cbr\u003e\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/cqrs.jpg)) \n[Fig. 22: Go, Jayson. _From Monolith to Event-Driven: Finding Seams in Your Future Architecture_](https://www.eventstore.com/blog/what-is-event-sourcing)\n\n### Command's pipeline\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/add-ha-message-queue.png) \n[Fig. 23: MSDN. _Use message queues (out-of-proc) in the command's pipeline_](https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/microservice-application-layer-implementation-web-api#use-message-queues-out-of-proc-in-the-commands-pipeline)\n\n### Projections\n\nTo cover this topic was\nprepared [this presentation](https://www.canva.com/design/DAEY9ttmPgY/F_lh7TXQEdG-su-qojEjdw/view?utm_content=DAEY9ttmPgY\u0026utm_campaign=designshare\u0026utm_medium=link\u0026utm_source=publishsharelink)\nwith some different strategies and ways to implement projections.\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/projections.svg)\n\n### CQRS + Event Sourcing\n\n\u003e CQRS and Event Sourcing have a symbiotic relationship. CQRS allows Event Sourcing to be used as the data storage mechanism for the domain.\n\u003e\n\u003e Young Greg, 2012, _CQRS and Event Sourcing_, **CQRS Documents by Greg Young**, p50.\n\n\u003e The CQRS pattern is often used along with the Event Sourcing pattern. CQRS-based systems use separate read and write data models, each tailored to relevant tasks and often located in physically\n\u003e separate stores. When used with the Event Sourcing pattern, the store of events is the write model, and is the official source of information. The read model of a CQRS-based system provides\n\u003e materialized views of the data, typically as highly denormalized views. These views are tailored to the interfaces and display requirements of the application, which helps to maximize both display\n\u003e and query performance.\n\u003e\n\u003e [\"Event Sourcing and CQRS pattern\" _MSDN_, Microsoft Docs, last edited on 02 Nov 2020](https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs#event-sourcing-and-cqrs-pattern)\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/cqrs-eventsourcing-diagram.png)\n[Fig. 24: Whittaker, Daniel. _CQRS + Event Sourcing – Step by Step_](https://danielwhittaker.me/2020/02/20/cqrs-step-step-guide-flow-typical-application)\n\n\u003cbr\u003e\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/cqrs-eventsourcing-flow.png) \n[Fig. 25: Katwatka, Piotr. _Event Sourcing with CQRS_](https://www.divante.com/blog/event-sourcing-open-loyalty-engineering)\n\n#### Capability Map\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/CQRS_ES_Capability_Map.jpeg)\n[Fig. 26: Nair, Vijay. _Distilling the CQRS/ES Capability_](https://developer.axoniq.io/w/distilling-the-cqrs/es-capability)\n\n### Commands vs Events\n\n\u003e Events represent a past, something that already happened and can't be undone. Commands, on the other hand, represent a wish, an action in the future which can be rejected. An event has typically\n\u003e multiple consumers, but a command is addressed to only one.\n\u003e\n\u003e [Tulka, Tomas. \"Events vs. Commands in DDD\", _blog.ttulka.com_, last edited on 25 Mar 2020](https://blog.ttulka.com/events-vs-commands-in-ddd)\n\n#### Domain Event\n\n\u003e In domain-driven design, domain events are described as something that happens in the domain and is important to domain experts. Such events typically occur regardless of whether or to what extent\n\u003e the domain is implemented in a software system. They are also independent of technologies. Accordingly, domain events have a high-value semantics, which is expressed in the language spoken by domain\n\u003e experts.\n\u003e\n\u003e [Stettler, Christina. \"Domain Events vs. Event Sourcing\", _innoq.com_, last edited on 15 Jan 2019](https://www.innoq.com/en/blog/domain-events-versus-event-sourcing)\n\n\u003e Event Sourcing is when you use Domain Events to store the state of an Aggregate within a Bounded Context. This basically means replacing your relational data model (or other data store) with an\n\u003e ever-growing log of Domain Events, which is called an event store. This is the core of Event Sourcing. So to use Event Sourcing you definitely need to understand Domain Events.\n\u003e\n\u003e [Holmqvist, Mattias. \"What are Domain Events?\", _serialized.io_, last edited on 20 Aug 2020](https://serialized.io/ddd/domain-event)\n\n#### Integration Event\n\n\u003e Integration events are used for bringing domain state in sync across multiple microservices or external systems. This functionality is done by publishing integration events outside the microservice.\n\u003e When an event is published to multiple receiver microservices (to as many microservices as are subscribed to the integration event), the appropriate event handler in each receiver microservice\n\u003e handles the event.\n\u003e\n\u003e [MSDN. \"Implementing event-based communication between microservices (integration events)\", _docs.microsoft.com_, last edited on 30 Nov 2021](https://docs.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/integration-event-based-microservice-communications)\n\n\u003e Should you publish Domain Events or Integration Events? Common advice is to not publish domain events outside of your service boundary. They should only exist within your service boundary. Instead,\n\u003e you should publish integration events for other service boundaries. While this general advice makes sense, it’s not so cut-and-dry. There are many reasons why you would want to publish domain events\n\u003e for other services to consume.\n\u003e\n\u003e Domain Events or Integration Events? As always, it depends. If your domain events are stable business concepts and they are understood outside of your boundary as a part of a long-running business\n\u003e process, then yes, publishing domain events outside of your boundary are acceptable. If events are used for data propagation or are more CRUD in nature, then publish Integration Events.\n\u003e\n\u003e [Comartin, Derek. \"Should you publish Domain Events or Integration Events?\", _codeopinion.com_, last edited on 24 Nov 2021](https://codeopinion.com/should-you-publish-domain-events-or-integration-events)\n\n#### Event Notification\n\n\u003e Most times events used for notifications are generally pretty slim. They don’t contain much data. If a consumer is handling an event but needs more information, to, for example, react and perform\n\u003e some action, it might have to make an RPC call back to the producing service to get more information. And this is what leads people to Event carried State Transfer, so they do not have to make these\n\u003e RPC calls.\n\u003e\n\u003e [Comartin, Derek. \"Event Based Architecture: What do you mean by EVENT?\", _codeopinion.com_, last edited on 05 Mai 2021](https://codeopinion.com/should-you-publish-domain-events-or-integration-events)\n\n\u003e In this mode, the event producer sends a notification to the event system that a change has happened to the entity. The change itself was NOT specified in the event. Consumers are expected to query\n\u003e the read endpoint to understand the latest state of the data.\n\u003e\n\u003e [Balachandran, Arvind. \"Event Notification vs. Event-Carried State Transfer\", _Start it up_, last edited on 27 Oct 2019](https://medium.com/swlh/event-notification-vs-event-carried-state-transfer-2e4fdf8f6662)\n\n#### Event-Carried State Transfer\n\n\u003e The most common way I see events being used and explained is for state propagation. Meaning, you’re publishing events about state changes within a service, so other services (consumers) can keep a\n\u003e local cache copy of the data.\n\u003e\n\u003eThis is often referred to as Event Carried State Transfer.\n\u003e\n\u003eThe reason services will want a local cache copy of another service’s data, is so they do not need to make RPC calls to other services to get data. The issue with making the RPC call is if there are\n\u003e issues with availability or latency, the call might fail. In order to be available when other services are unavailable, they want the data they need locally.\n\u003e\n\u003e [Comartin, Derek. \"Event Based Architecture: What do you mean by EVENT?\", _codeopinion.com_, last edited on 05 Mai 2021](https://codeopinion.com/should-you-publish-domain-events-or-integration-events)\n\n\u003e In stark contrast to the event notification model, the event-carried state transfer model puts the data as part of the event itself. There are two key variants to implementing this. Fine-Grained and\n\u003e Snapshots.\n\u003e\n\u003e [Balachandran, Arvind. \"Event Notification vs. Event-Carried State Transfer\", _Start it up_, last edited on 27 Oct 2019](https://medium.com/swlh/event-notification-vs-event-carried-state-transfer-2e4fdf8f6662)\n\n#### Summary Event\n\n\u003e Instead of emitting each event, the original business process can keep all the events private. At the end of the process, the process emits a single Summary Event. This event is redundant, in the\n\u003e sense that it contains only information that was already available in the preceding events. Consumers, instead of being aware of every event, are now only listening to this Summary Event, which tells\n\u003e them everything they need to know, with little to no irrelevant (to them) information. Consumers do not need to track state changes during the process, because they get everything at the end, and can\n\u003e then act on them.\n\u003e\n\u003e [Verraes, Mathias. \"Patterns for Decoupling in Distributed Systems: Summary Event\", _verraes.net_, last edited on 08 May 2019](https://verraes.net/2019/05/patterns-for-decoupling-distsys-summary-event/)\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003eTask Based UI + CQRS\u003c/summary\u003e\n\n### Task Based UI + CQRS\n\nIn a standard user interface (UI), the user typically edits or manipulates data directly. This allows the user to enter or modify the data synchronously, enabling the UI to respond to\nthe user's actions in real-time (blocking the operation until the return).\n\nIn a task-based UI, on the other hand, the user typically expresses their intentions rather than editing the data directly. Task-based UIs provide users with the information and tools to\ncomplete specific tasks. They generally are organized around the steps or stages of the task, and give the user instructions, prompts, and input fields to enter or modify a specific piece of data.\n\nTask Based UI can use asynchronous communication mechanisms to enable users to express their intentions asynchronously, without the need for the UI to wait for a response or confirmation from the system.\nFor example, the UI may use a message queue or event bus to send commands or messages to the system, and the system may use the same mechanism to send updates or notifications back to the UI. This\nenable the UI to continue with other operations, such as querying the system for updated data or displaying a progress indicator to the user without waiting for a response from the system.\n\nHowever, even though a way command does not require a return value or confirmation, it can still be validated and accepted by the CQRS system. When a way command is received by the write side of the\nCQRS system, it can be validated to ensure that it is well-formed and conforms to the rules and constraints of the system. If the command is valid, it can be accepted and processed, and the data can\nbe updated or modified according to the instructions in the command. If the command is not valid, it can be rejected or ignored, and the data can be left unchanged.\n\nTask-based UIs and CQRS can be used together to provide users with a flexible and efficient way to interact with a system and complete specific tasks. This can make them more efficient and\nuser-friendly than more general-purpose UIs.\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/task_based_ui.png) \n[Fig. 26: Murali, Bala. _What is Task Based UI_](https://medium.com/@baladotcom/what-is-task-based-ui-60a44ddfd968)\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003eEventStorming\u003c/summary\u003e\n\n### EventStorming\n\n\u003e EventStorming is a flexible workshop format for collaborative exploration of complex business domains.\n\u003e\n\u003eIt comes in different flavours, that can be used in different scenarios:\n\u003e\n\u003e - to assess health of an existing line of business and to discover the most effective areas for improvements;\n\u003e - to explore the viability of a new startup business model;\n\u003e - to envision new services, that maximise positive outcomes to every party involved;\n\u003e - to design clean and maintainable Event-Driven software, to support rapidly evolving businesses.\n\u003e\n\u003e The adaptive nature of EventStorming allows sophisticated cross-discipline conversation between stakeholders with different backgrounds, delivering a new type of collaboration beyond silo and\n\u003e specialisation boundaries.\n\u003e\n\u003e [Brandolini, Alberto. \"EventStorming\", _EventStorming.com_, last edited on 2020](https://www.eventstorming.com)\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/event-storming.jpg) \n[Fig. 27: Baas-Schwegler, Kenny \u0026 Richardson, Chris. _Picture that explains \"Almost\" Everything_](https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet)\n\n### EventStorming (WIP)\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/event-storming-wip.jpg)\n\n#### Authentication flow\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/authentication.jpg)\n\n### From EventStorming to Event Sourcing\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/from-eventstorming-to-eventsourcing.png)\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003eClean Architecture\u003c/summary\u003e\n\n### Clean Architecture\n\n\u003e Clean architecture is a software design philosophy that separates the elements of a design into ring levels. An important goal of clean architecture is to provide developers with a way to organize\n\u003e code in such a way that it encapsulates the business logic but keeps it separate from the delivery mechanism.\n\u003e\n\u003e The main rule of clean architecture is that code dependencies can only move from the outer levels inward. Code on the inner layers can have no knowledge of functions on the outer layers. The\n\u003e variables, functions and classes (any entities) that exist in the outer layers can not be mentioned in the more inward levels. It is recommended that data formats also stay separate between levels.\n\u003e\n\u003e [\"Clean Architecture.\" _Whatis_, last edited on 10 Mar 2019](https://whatis.techtarget.com/definition/clean-architecture)\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/CleanArchitecture.jpg) \n[Fig. 28: C. Martin, Robert. _The Clean Architecture_](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)\n\n#### Diagram\n\n![](https://raw.githubusercontent.com/AntonioFalcaoJr/EventualShop/release/.assets/img/CleanArchitectureDiagram.png)\n\n\u003c/details\u003e\n\n## :rocket: Performance\n\n\u003cdetails\u003e\n \u003csummary\u003eAsync Projections\u003c/summary\u003e\n\n### Async Projections\n\nIn a Command and Query Responsibility Segregation (CQRS) system, denormalized asynchronous projections can significantly improve performance for several reasons:\n\n- Improved Read Performance: In a CQRS system, the read side is separate from the write side and is optimized for querying data. By denormalizing the data in the projections, the read side can access\nthe data it needs more efficiently, reducing the number of joins required to retrieve data and ultimately speeding up query performance.\n\n- Reduced Latency: When data is denormalized, it's usually stored in a format that's more suitable for the specific use case. This can reduce the amount of data that needs to be retrieved from the\ndatabase, which can help to minimize latency and improve the overall responsiveness of the system.\n\n- Increased Scalability: Denormalized projections can handle a larger volume of data more efficiently than normalized ones. This is because denormalized data is usually stored in a format that's\noptimized for a specific use case, which allows the system to process the data more quickly and with less resources.\n\n- Simpler Architecture: In a normalized data model, data is often spread out across multiple tables, which can make the system more complex to design, develop, and maintain. By denormalizing the data,\nit can be easier to manage and understand, which can simplify the overall architecture and make the system more maintainable.\n\n- Improved Concurrency: Asynchronous projections allow multiple operations to be performed at the same time and, denormalized projections reduce contention, helping to improve concurrent write operation\nperformance.\n\nIn summary, denormalized asynchronous projections in a CQRS system can help to improve performance by reducing latency, increasing scalability, simplifying the architecture, and improving concurrency.\nThis results in a more responsive and efficient system that can handle larger volumes of data and more complex queries.\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003eSnapshotting\u003c/summary\u003e\n\n### Snapshotting\n\n\u003e Snapshotting is an optimisation that reduces time spent on reading event from an event store.\n\u003e\n\u003e [Gunia, Kacper. \"Event Sourcing: Snapshotting\", _domaincentric.net_, last edited on 5 Jun 2020](https://domaincentric.net/blog/event-sourcing-snapshotting)\n\nMore details in [snapshot](#snapshot) section.\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003eMinimize Exceptions\u003c/summary\u003e\n\n### Minimize Exceptions\n\n\u003e Exceptions should be rare. Throwing and catching exceptions is slow relative to other code flow patterns. Because of this, exceptions shouldn't be used to control normal program flow.\n\u003e\n\u003e Recommendations:\n\u003e\n\u003e - Do not use throwing or catching exceptions as a means of normal program flow, especially in hot code paths.\n\u003e - Do include logic in the app to detect and handle conditions that would cause an exception.\n\u003e - Do throw or catch exceptions for unusual or unexpected conditions.\n\u003e - App diagnostic tools, such as Application Insights, can help to identify common exceptions in an app that may affect performance.\n\u003e\n\u003e [\"ASP.NET Core Performance Best Practices\" _MSDN_, Microsoft Docs, last edited on 18 Fev 2022](https://docs.microsoft.com/en-us/aspnet/core/performance/performance-best-practices?view=aspnetcore-6.0#minimize-exceptions)\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003ePool HTTP connections with HttpClientFactory\u003c/summary\u003e\n\n### Pool HTTP connections with HttpClientFactory\n\n\u003e Closed `HttpClient` instances leave sockets open in the `TIME_WAIT` state for a short period of time. If a code path that creates and disposes of `HttpClient` objects is frequently used, the app may\n\u003e exhaust available sockets.\n\u003e\n\u003e Recommendations:\n\u003e\n\u003e - Do not create and dispose of HttpClient instances directly.\n\u003e - Do use HttpClientFactory to retrieve HttpClient instances.\n\u003e\n\u003e [\"ASP.NET Core Performance Best Practices\" _MSDN_, Microsoft Docs, last edited on 18 Fev 2022](https://docs.microsoft.com/en-us/aspnet/core/performance/performance-best-practices?view=aspnetcore-6.0#pool-http-connections-with-httpclientfactory)\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003eDbContext Pooling\u003c/summary\u003e\n\n### DbContext Pooling\n\n\u003e The basic pattern for using EF Core in an ASP.NET Core application usually involves registering a custom DbContext type into the dependency injection system and later obtaining instances of that\n\u003e type through constructor parameters in controllers. This means a new instance of the DbContext is created for each request.\n\u003e\n\u003e In version 2.0 we are introducing a new way to register custom DbContext types in dependency injection which transparently introduces a pool of reusable DbContext instances. This is conceptually\n\u003e similar to how connection pooling operates in ADO.NET providers and has the advantage of saving some of the cost of initialization of DbContext instance.\n\u003e\n\u003e [\"New features in EF Core 2.0\" _MSDN_, Microsoft Docs, last edited on 11 Oct 2020](https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core-2.0/#dbcontext-pooling)\n\n\u003c/details\u003e\n\n## :computer: Running\n\nProjects may have different environments where the application runs: development, staging, production, etc. Usually, different environments should have different settings.\n\n\u003cdetails\u003e\n \u003csummary\u003eDevelopment\u003c/summary\u003e\n\n### Development\n\nDevelopment is usually a local environment. [Docker](https://www.docker.com/why-docker/) makes it easy to set up that closely mirrors the production environment without having to install and configure all of the dependencies on your local\nmachine. Especially useful for working on complex applications that rely on many different libraries and tools.\n\n#### Docker\n\nThe respective [./docker-compose.Development.Infrastructure.yaml](./docker-compose.Development.Infrastructure.yaml) will provide all the necessary resources, with public exposure to the connection\nports:\n\n```bash\ndocker-compose -f ./docker-compose.Development.Infrastructure.yaml up -d\n```\n\nIf prefer, is possible to use individual Docker commands:\n\nMSSQL\n\n```bash\ndocker run -d \\\n-e 'ACCEPT_EULA=Y' \\\n-e 'SA_PASSWORD=!MyStrongPassword' \\\n-p 1433:1433 \\\n--name mssql \\\nmcr.microsoft.com/mssql/server\n```\n\nMongoDB\n\n```bash\ndocker run -d \\\n-e 'MONGO_INITDB_ROOT_USERNAME=mongoadmin' \\\n-e 'MONGO_INITDB_ROOT_PASSWORD=secret' \\\n-p 27017:27017 \\\n--name mongodb \\\nmongo\n```\n\nRabbitMQ\n\n```bash\ndocker run -d \\\n-p 15672:15672 \\\n-p 5672:5672 \\\n--hostname my-rabbit \\\n--name rabbitmq \\\nrabbitmq:3-management\n```\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003eStaging\u003c/summary\u003e\n\n### Staging\n\nThe staging environment is for testing and homologation; It resembles the production environment. In other words, it's a complete but independent copy of the production environment, including seeding\ndata if needed.\n\nBased on a containerized system, the staging environment is provided via Docker Compose. On each `appsettings.Staging.json` the integrations are configured by name, taking advantage from the Docker\nnetwork interface with DNS services.\n\n#### Docker-compose\n\nThe resources were split into two files: \n\n- [`docker-compose.Staging.Infrastructure.yaml`](./docker-compose.Staging.Infrastructure.yaml), connection ports are privately exposed only; \n- [`docker-compose.Staging.Services.yaml`](./docker-compose.Staging.Services.yaml), services connected by DNS names.\n\n```bash\ndocker-compose \\\n-f ./docker-compose.Staging.Infrastructure.yaml \\\n-f ./docker-compose.Staging.Services.yaml \\\nup -d\n``` \n\n##### Deployment\n\nReplicas count and resources allocation can be configured straight on respective composes files:\n\n```yaml\ndeploy:\n replicas: 2\n resources:\n limits:\n cpus: '0.20'\n memory: 200M\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003eProduction\u003c/summary\u003e\n\n### Production\n\n// TODO\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003eMigrations\u003c/summary\u003e\n\n### EF Core Migrations\n\nIf it's needed to change the **Event Store** structure, a new _migration_ should be built:\n\n```bash\ndotnet ef migrations add \"First Migration\" -s .\\WorkerService\\ -p .\\Infrastructure.EventStore\\\n```\n\nThe database update is automatically executed at the command-stack Worker Services [Program.cs](./src/Services/Account/Command/WorkerService/Program.cs), for **Development** and **Staging** environments:\n\n```csharp\nvar environment = host.Services.GetRequiredService\u003cIHostEnvironment\u003e();\n\nif (environment.IsDevelopment() || environment.IsStaging())\n{\n await using var scope = host.Services.CreateAsyncScope();\n await using var dbContext = scope.ServiceProvider.GetRequiredService\u003cEventStoreDbContext\u003e();\n await dbContext.Database.MigrateAsync();\n await dbContext.Database.EnsureCreatedAsync();\n}\n```\n\n\u003c/details\u003e\n\n## :test_tube: Tests\n\n\u003cdetails\u003e\n \u003csummary\u003eUnit Tests\u003c/summary\u003e\n\n### Unit Tests\n\nTo unit-test an event-sourced aggregate, it's to verify that the Aggregate produces the expected event as output given a specific set of input Events and a Command. This involves creating an Aggregate\ninstance, applying the input events to it, handling the command, and verifying the expected event output.\n\n```csharp\n[Fact]\npublic void CreateCartShouldRaiseCartCreated()\n =\u003e Given\u003cShoppingCart\u003e()\n .When\u003cCommand.CreateCart\u003e(new(_cartId, _customerId))\n .Then\u003cDomainEvent.CartCreated\u003e(\n @event =\u003e @event.CartId.Should().Be(_cartId),\n @event =\u003e @event.CustomerId.Should().Be(_customerId),\n @event =\u003e @event.Status.Should().Be(CartStatus.Active));\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003eIntegration Tests\u003c/summary\u003e\n\n### Integration Tests\n\n// TODO\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n \u003csummary\u003eLoad Tests\u003c/summary\u003e\n\n### Load Testing (K6)\n\n```bash\ndocker run --network=internal --name k6 --rm -i grafana/k6 run - \u003ctest.js\n```\n\n\u003c/details\u003e\n\n## :book: References\n\n### Books\n\n- [Evans, Eric (2003), Domain-Driven Design: Tackling Complexity in the Heart of Software.](https://www.amazon.com/dp-0321125215/dp/0321125215/ref=mt_other?_encoding=UTF8\u0026me=\u0026qid=1641385448)\n- [Hohpe, Gregor (2003), Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions](https://www.enterpriseintegrationpatterns.com/)\n- [Young, Greg (2012), Event Centric: Finding Simplicity in Complex Systems.](https://www.amazon.com/Event-Centric-Simplicity-Addison-Wesley-Signature/dp/0321768221)\n- [Vernon, Vaughn (2016), Domain-Driven Design Distilled.](https://www.amazon.com/dp-0134434420/dp/0134434420/ref=mt_other?_encoding=UTF8\u0026me=\u0026qid=1641385096)\n- [Richardson, Chris (2018), Microservices Patterns: With examples in Java.](https://www.amazon.com/-/pt/dp-B09782192F/dp/B09782192F/ref=mt_other?_encoding=UTF8\u0026me=\u0026qid=1641385683)\n\n### Articles\n\n- [Effective Aggregate Design Part I: Modeling a Single Aggregate](https://www.dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf)\n- [Effective Aggregate Design Part II: Making Aggregates Work Together](https://www.dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_2.pdf)\n- [Effective Aggregate Design Part III: Gaining Insight Through Discovery](https://www.dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_3.pdf)\n- [CQRS Documents - Greg Young](https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf)\n- [Versioning in an Event Sourced - Greg Young](https://leanpub.com/esversioning/read)\n- [Clarified CQRS - Udi Dahan](https://udidahan.com/wp-content/uploads/Clarified_CQRS.pdf)\n\n### Blogs\n\n- [Event-driven IO - Oskar Dudycz](https://event-driven.io/)\n- [Code Opinion - Derek Comartin](https://codeopinion.com/)\n- [Domain Centric - Kacper Gunia](https://domaincentric.net/)\n- [CQRS Event Sourcing - Daniel Whittaker](https://danielwhittaker.me/)\n- [Event Store - Alexey Zimarev](https://www.eventstore.com/blog)\n- [Mathias Verraes Student of Systems](https://verraes.net/)\n\n### Posts\n\n- [Modeling Uncertainty with Reactive DDD - Vaughn Vernon](https://www.infoq.com/articles/modeling-uncertainty-reactive-ddd/)\n- [Reactive DDD—When Concurrent Waxes Fluent - Vaughn Vernon](https://www.infoq.com/presentations/reactive-ddd/)\n- [Pattern: Event sourcing - Chris Richardson](https://microservices.io/patterns/data/event-sourcing.html)\n- [Clarified CQRS - Udi Dahan](https://udidahan.com/2009/12/09/clarified-cqrs/)\n- [Udi \u0026 Greg Reach CQRS Agreement](https://udidahan.com/2012/02/10/udi-greg-reach-cqrs-agreement/)\n- [Event Sourcing and CQRS - Alexey Zimarev](https://www.eventstore.com/blog/event-sourcing-and-cqrs)\n- [What is Event Sourcing? - Alexey Zimarev](https://www.eventstore.com/blog/what-is-event-sourcing)\n- [Transcript of Greg Young's Talk at Code on the Beach 2014: CQRS and Event Sourcing](https://www.eventstore.com/blog/transcript-of-greg-youngs-talk-at-code-on-the-beach-2014-cqrs-and-event-sourcing)\n- [Introduction to CQRS - Kanasz Robert](https://www.codeproject.com/Articles/555855/Introduction-to-CQRS)\n- [Distilling the CQRS/ES Capability - Vijay Nair](https://axoniq.io/blog-overview/distilling-the-cqrses-capability)\n- [Dispelling the Eventual Consistency FUD when using Event Sourcing - Vijay Nair](https://axoniq.io/blog-overview/dispelling-the-eventual-consistency-fud-when-using-event-sourcing)\n- [Why would I need a specialized Event Store? - Greg Woods](https://axoniq.io/blog-overview/eventstore)\n- [A Fast and Lightweight Solution for CQRS and Event Sourcing - Daniel Miller](https://www.codeproject.com/Articles/5264244/A-Fast-and-Lightweight-Solution-for-CQRS-and-Event)\n- [Event Sourcing: The Good, The Bad and The Ugly - Dennis Doomen](https://www.continuousimprover.com/2017/11/event-sourcing-good-bad-and-ugly.html)\n- [What they don’t tell you about event sourcing - Hugo Rocha](https://medium.com/@hugo.oliveira.rocha/what-they-dont-tell-you-about-event-sourcing-6afc23c69e9a)\n- [Event Sourcing pattern - MSDN](https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing)\n- [CQRS + Event Sourcing, Step by Step - Daniel](https://danielwhittaker.me/2020/02/20/cqrs-step-step-guide-flow-typical-application/)\n- [Architectural considerations for event-driven microservices-based systems - Tanmay Ambre](https://developer.ibm.com/articles/eda-and-microservices-architecture-best-practices/)\n- [How messaging simplifies and strengthens your microservice application - Callum Jackson](https://developer.ibm.com/articles/how-messaging-simplifies-strengthens-microservice-applications/)\n- [Event Sourcing: Aggregates Vs Projections - Kacper Gunia](https://domaincentric.net/blog/event-sourcing-aggregates-vs-projections)\n- [Event Sourcing: Projections - Kacper Gunia](https://domaincentric.net/blog/event-sourcing-projections)\n- [Advantages of the event-driven architecture pattern - Grace Jansen \u0026 Johanna Saladas](https://developer.ibm.com/articles/advantages-of-an-event-driven-architecture/)\n- [CQRS - Martin Fowler](https://martinfowler.com/bliki/CQRS.html)\n\n### Projects\n\n- [Simple CQRS example - Greg Young](https://github.com/gregoryyoung/m-r)\n- [EventSourcing.NetCore - Oskar Dudycz](https://github.com/oskardudycz/EventSourcing.NetCore)\n\n## :toolbox: Tech Stack\n\n### Worker Services\n\n- [.NET 8](https://dotnet.microsoft.com/en-us/) - A free, multi/cross-platform and open-source framework;\n- [EF Core 8](https://devblogs.microsoft.com/dotnet/announcing-ef7/) - An open source object–relational mapping framework for ADO.NET;\n- [MSSQL](https://hub.docker.com/_/microsoft-mssql-server) - A relational database management system (Event Store Database);\n- [MongoDB](https://www.mongodb.com/docs/drivers/csharp/) - A source-available cross-platform document-oriented database (Projections Database);\n- [MassTransit](https://masstransit-project.com/) - Message Bus;\n- [FluentValidation](https://fluentvalidation.net/) - A popular .NET library for building strongly-typed validation rules;\n- [Serilog](https://serilog.net/) - A diagnostic logging to files, console and elsewhere.\n\n### Web API\n\n- [ASP.NET Core 8](https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-net-7-preview-1/) - A free, cross-platform and open-source web-development framework;\n- [MassTransit](https://masstransit-project.com/) - Message Bus;\n- [FluentValidation](https://fluentvalidation.net/) - A popular .NET library for building strongly-typed validation rules;\n- [Serilog](https://serilog.net/) - A diagnostic logging to files, console and elsewhere.\n\n### Web APP\n\n- [Blazor WASM](https://docs.microsoft.com/en-us/aspnet/core/blazor/?WT.mc_id=dotnet-35129-website\u0026view=aspnetcore-6.0#blazor-webassembly) - Is a single-page app (SPA) framework for building\n interactive client-side web apps with .NET;\n- [BlazorStrap](https://blazorstrap.io/V5/) - Bootstrap 5 Components for Blazor Framework;\n\n## Contributing\n\nAll contributions are welcome. Please take a look at [contributing](./CONTRIBUTING.md) guide.\n\n## Versioning\n\nWe use [SemVer](http://semver.org/) for versioning. For the versions available, see the [tags on this repository](https://github.com/AntonioFalcao/EventualShop/tags).\n\n## Authors\n\n\u003e See the list of [contributors](https://github.com/AntonioFalcao/EventualShop/graphs/contributors) who participated in this project.\n\n## License\n\nThis project is licensed under the MIT License - see the [LICENSE](./LICENSE) file for details\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FAntonioFalcaoJr%2FEventualShop","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FAntonioFalcaoJr%2FEventualShop","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FAntonioFalcaoJr%2FEventualShop/lists"}