https://github.com/NHadi/Pos
Sample Application DDD, Reactive Microservices, CQRS Event Sourcing Powered by DERMAYON LIBRARY
https://github.com/NHadi/Pos
cqrs cqrs-es ddd-architecture event-driven event-sourcing generic-repository kafka microservices microservices-architecture netcore reactive
Last synced: 25 days ago
JSON representation
Sample Application DDD, Reactive Microservices, CQRS Event Sourcing Powered by DERMAYON LIBRARY
- Host: GitHub
- URL: https://github.com/NHadi/Pos
- Owner: NHadi
- Created: 2019-11-02T07:48:10.000Z (over 5 years ago)
- Default Branch: master
- Last Pushed: 2019-11-12T04:31:55.000Z (over 5 years ago)
- Last Synced: 2024-08-03T23:24:04.381Z (10 months ago)
- Topics: cqrs, cqrs-es, ddd-architecture, event-driven, event-sourcing, generic-repository, kafka, microservices, microservices-architecture, netcore, reactive
- Language: JavaScript
- Homepage:
- Size: 15.8 MB
- Stars: 310
- Watchers: 44
- Forks: 138
- Open Issues: 3
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
- awesome-dotnet-core-applications - **Pos** - is a sample project demonstrating the use of microservices. (Sample & Reference Applications)
README
# POS - DDD, Reactive Microservices, CQRS Event Sourcing Powered by DERMAYON LIBRARY
Sample Application DDD Reactive Microservices with CQRS & Event Sourcing with [DERMAYON LIBRARY](https://github.com/NHadi/Dermayon).
# Architectures
# Features
1. Microservices
2. CQRS (Command Query Responsibility Segregation)
3. Event Sourcing
4. Generic Repository
5. UnitOfWork
6. Domain Driven Design
7. Api Gateway [Ocelot](https://ocelot.readthedocs.io/en/latest/introduction/gettingstarted.html)
8. Multiple Databases type [MongoDb, SqlServer, etc]
9. Message Broker [Kafka]
# Information
1. Domain Layer : Main of Application like Event, Repository, etc
2. Infrastructure Layer : Databases, Files, etc
3. 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
1. Highly maintainable and testable
2. Loosely coupled
3. Independently deployable
4. Organized around business capabilities
5. 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](https://microservices.io/)
# 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.
1. Responsiveness means the service should respond in a timely manner.
2. Resilience goes in line with responsiveness, the system should respond even in the face of failure.
3. 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.
4. 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.
## Get started
**Clone the repository**
**Run and Build the app**
```sh
cd Pos
docker-compose up
```
wait for completed
**List Url:Port the app**
```sh
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
1. Product Services = localhost[::]/api-product/[action]
2. Customer Services = localhost[::]/api-customer/[action]
3. Order Services = localhost[::]/api-order/[action]
4. Report Services = localhost[::]/api-report/[action]
# Check Healty All Services
Keep Updates, I'will update for new best practices of technology & software design, architectural
# Thanks