POS - DDD, Reactive Microservices, CQRS Event Sourcing Powered by DERMAYON LIBRARY

Sample Application DDD Reactive Microservices with CQRS & Event Sourcing with DERMAYON LIBRARY.

Architectures

Features

Microservices
CQRS (Command Query Responsibility Segregation)
Event Sourcing
Generic Repository
UnitOfWork
Domain Driven Design
Api Gateway Ocelot
Multiple Databases type [MongoDb, SqlServer, etc]
Message Broker [Kafka]

Information

Domain Layer : Main of Application like Event, Repository, etc
Infrastructure Layer : Databases, Files, etc
Application Layer : WebApi, etc

Main Architecture

Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are

Highly maintainable and testable
Loosely coupled
Independently deployable
Organized around business capabilities
Owned by a small team

The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack. reference

API Gateway

The API Gateway encapsulates the internal system architecture and provides an API that is tailored to each client. It might have other responsibilities such as authentication, monitoring, load balancing, caching,

CQRS Event Sourcing

CQRS stands for Command Query Responsibility Segregation. It's a pattern that I first heard described by Greg Young. At its heart is the notion that you can use a different model to update information than the model you use to read information. For some situations, this separation can be valuable, but beware that for most systems CQRS adds risky complexity.

Benefits when to use CQRS Event Sourcing

imagine if the system is too complex and more than 1K user hit in server, how many related tables? and how long does it take to get data? with cqrs & event sourcing we can implement materialized views, or in other words denormalized tables into one data or flat

Reactive Services, Reactive Manifesto, and Microservices

The Reactive Manifesto outlines qualities of Reactive Systems based on four principles: Responsive, Resilient, Elastic and Message Driven.

Responsiveness means the service should respond in a timely manner.
Resilience goes in line with responsiveness, the system should respond even in the face of failure.
Elasticity works with resilience. The ability to spin up new services and for downstream and upstream services and clients to find the new instances is vital to both the resilience of the system as well as the elasticity of the system.
Message Driven: Reactive Systems rely on asynchronous message passing. This established boundaries between services (in-proc and out of proc) which allows for loose coupling (publish/subscribe or async streams or async calls), isolation (one failure does not ripple through to upstream services and clients), and improved responsive error handling.