Project Structure
Overview¶
The primary service footprint of Otto is structured as a modular monolith. The main benefits include:
- Project setup is straightforward.
- Bounded context concerns are maintained via modules.
- Modules have a much lower cost to add vs services.
- A single database is used, separated by schemas.
- A single deployment pipeline is maintained.
See modular monolith ADR.
docs\arch\adr\adr-002.md
Namespace¶
JHA.PayCenter.Otto: Root for project JHA.PayCenter.Otto.OttoServices: Primary API service
Repository structure¶
Proposed GitHub repo: https://github.com/JHPaymentSolutions/PC-Otto
Otto utilizes a mono repo.
README.md
src
/BuildingBlocks
# Most of these can be from Blue via nuget
Otto.BuildingBlocks.Application
Otto.BuildingBlocks.Contracts
Otto.BuildingBlocks.Infrastructure
Otto.BuildingBlocks.Infrastructure.Db
Otto.BuildingBlocks.Infrastructure.Db.Tests
Otto.BuildingBlocks.Logging
Otto.BuildingBlocks.Middleware
Otto.BuildingBlocks.Seedwork
Otto.BuildingBlocks.TestSupport
Otto.BuildingBlocks.Unit.Tests
/Services # Each service is a deployable unit. Currently one service is defined.
/Otto # modular monolith - JHA.PayCenter.Otto.OttoServices
/API
/OttoServices.API
OttoServices.API.csproj
/Extensions
/Modules
/Health # Feature-level folders that match Health.Application
/Integrity # Feature-level folders that match Integrity.Application
/Features
# Each feature folder contains controllers and models
/CoreTransactions
/CprPayments
/ReportingPayments
/Payments # if we have rail-agnostic REST endpoints
/wwwroot
/Listener
Listener.csproj # stream consumer
/openapi
/v1
OttoServices.Health.yaml
OttoServices.Integrity.yaml
/Integrity.Infrastructure.Db
# Each module has a schema that lives in the service's database.
# This is the sole DbUp project that handles the migrations for the service.
/Modules
/Health
/Health.Application
Otto.OttoServices.Health.Application
/Features
/Integrity
/Integrity.Application
# Command/Query request handlers by feature
Integrity.Application.csproj
/Features
# Each feature folder generally contains:
# - REST API handlers for model
# - It is common for a feature to line up with a /resource
# - Broker event handlers
# - Broker command response handlers
/CoreTransactions
/CprPayments
/Payments # API handlers, if any
/ReportingPayments
/RulesSets
# Domain event handlers to initiate rules by payment
# Command handlers to run schedule rule checks
# REST API handlers relating to rule set
/Rules
# REST API handlers relating to rule-level operations:
# - Ops team overrides
/Integrity.Domain
Integrity.Domain.csproj
# The domain does not have vertical slices/features.
/Common
/Aggregate1
/Aggregate2
/Services # domain services
/Integrity.Infrastructure
Integrity.Infrastructure.csproj
/Repositories # If using repository pattern
/Integrity.Integration.Tests
Integrity.Integration.Tests.csproj