example project to better understand how microservices architecture function.
what parts of it were developed here :
- when applying migrations, it helps to override the connection string of the serivce in
docker-compose.yml
.
like a so:
catalog.api:
environment:
- "Connection string here!!"
image: ${DOCKER_REGISTRY-}catalogapi
build:
context: .
dockerfile: Services/Catalog/Catalog.API/Dockerfile
ports:
- "5001:80"
container_name: Catalog-API
depends_on:
- mongoProduct
responsible for the information of the protduct catalog.
- REST CRUD
- port: 5001
- repo pattern w/ mongo db
- Layered architecture - separated by folders not projects
- Infrastructer layer for Data Access and presistence of business state
- Domain layer for Business logic
- the heart of the application
- API/Application layer for Presentation layer, controllers in this case
- data transmission 2 user/other services
Responsible for the users basket and checkout
- repo pattern w/ redis-cache
- port: 5002
- REST CRUD
- Layered architecture - separated by folders not projects
- Infrastructer layer for Data Access and presistence of business state
- Domain layer for Business logic
- the heart of the application
- API/Application layer for Presentation layer, controllers in this case
- data transmission 2 user/other services
- repo pattern w/ postgress
- port: 5003
- REST CRUD
- Dapper as the smol ORM
- Layered architecture - separated by folders not projects
- Infrastructer layer for Data Access and presistence of business state
- Domain layer for Business logic
- the heart of the application
- API/Application layer for Presentation layer, controllers in this case
- data transmission 2 user/other services
- port: 5004
- Dapper as the smol ORM
- REST API w/ CRUD
- DDD, CQRS w/ MediatR, Clean Architecture
- this DDD, not this DDD
- Fluent Validation
- EF CORE
- Core
- Domain
- includes domain only objects
- ValueObject - Docs
- Application : Domain
- for everything related to Business
- Folders:
- Contracts : Application Capabilities ; Abstractions and Interfaces
- Behaviours : Contains Behaviours/Cross cutting concerns that apply when using the implementation ; Validation for example
- Features : CQRS related stuff that handles business cases
- Domain
- Infrastrucure : Application
- API : Application, Infra
migrate and apply
dotnet ef migrations add initial -p .\Ordering\Ordering.Infrastructure\Ordering.Infrastructure.csproj -s .\Ordering\Ordering.API\Ordering.API.csproj
dotnet ef database update -p .\Ordering\Ordering.Infrastructure\Ordering.Infrastructure.csproj -s .\Ordering\Ordering.API\Ordering.API.csproj
docker images management interface
- ports:
- 8080
- 9000 <- used one for the web interface
houses all the common things between the services, like the message classes
connect both the basket and the orders services via a shared queue
the basket emmits an event message the the orders consume it.
Ocelot BFF
creates a Facade around the exposed API endpoints, you'd have to create multiple Facades depending on the requirements.
don't put all ur Requests in One basket xD.
creates a facade for the user; instead of them sending (n) requests they only have to send one, the aggregrator takes care of aggregrating the relavent info then returns it to the requester in a single DTO.