Microservices-in-dotnet

example project to better understand how microservices architecture function.

what parts of it were developed here :

Services

• 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

---

Catalog

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

---

Basket

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

---

Discount

API

• 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

gRPC

• port: 5004
• Dapper as the smol ORM

---

Ordering API

• REST API w/ CRUD
• DDD, CQRS w/ MediatR, Clean Architecture
• this DDD, not this DDD
• Fluent Validation
• EF CORE

Layers

• 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
• 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

---

portainer

docker images management interface

• ports:
  • 8080
  • 9000 <- used one for the web interface

---

Building Block

houses all the common things between the services, like the message classes

---

Rabbit MQ and masstransit

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.

---

Request aggregrator

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.