POS - DDD, Reactive Microservices, CQRS Event Sourcing Powered by DERMAYON LIBRARY
Sample Application DDD Reactive Microservices with CQRS & Event Sourcing with DERMAYON LIBRARY.
- CQRS (Command Query Responsibility Segregation)
- Event Sourcing
- Generic Repository
- Domain Driven Design
- Api Gateway Ocelot
- Multiple Databases type [MongoDb, SqlServer, etc]
- Message Broker [Kafka]
- Domain Layer : Main of Application like Event, Repository, etc
- Infrastructure Layer : Databases, Files, etc
- Application Layer : WebApi, etc
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
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.
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.
Clone the repository
Run and Build the app
cd Pos docker-compose up
List Url:Port the app
docker container ls
For sample we can navigate to PRODUCT SERVICES ::localhost:32771/swagger
Running in GATEWAY
Navigate to postgateway for sample ::localhost:32768/[SERVICES]/[Action]
Sample Running in Gateway http://localhost:[PosGatewayPort]/api-product/productCategory/7a3fff4b-54ca-4c21-bf04-c11aea9b7673
List of Gateway Services
- Product Services = localhost[::]/api-product/[action]
- Customer Services = localhost[::]/api-customer/[action]
- Order Services = localhost[::]/api-order/[action]
- Report Services = localhost[::]/api-report/[action]
Check Healty All Services
Keep Updates, I'will update for new best practices of technology & software design, architectural