The software architecture of Scaffold has been heavily inspired by the Explicit Architecture presented in DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together by Herberto Graça. You can read his article by clicking here.
A software architecture provides a common language to help communicate the design and structure of a software system between different software developers.
The Primary / Driving Adapters for Scaffold currently live in the Sources directory along with the Application and Domain Layer. Each individual Primary / Driving Adapter is its own host and communicates with the Application Layer via the Command / Query Bus.
The Secondary / Driven Adapters for Scaffold are currently located in the Adapters directory. These adapters implement interfaces defined in the Application Layer and their concrete versions are intended to be provided via dependency injection.
The Command / Query Bus in Scaffold uses the mediator pattern which has been implemented with the help of the MediatR library. In this pattern, a Primary / Driving Adapter sends request objects to Command / Query Handlers in the Application Layer and receives responses via a mediator. The Primary / Driving Adapters and Command / Query Handlers do not know about each other.
To facilitate Component-to-Component communication and to keep Components decoupled from each other, Scaffold uses an in-process Event Bus which has been implemented with the help of the MediatR library. Instead of taking direct dependencies on each other, Components instead take a dependency on shared message formats.
Scaffold primarily organizes code using a Package by Layer approach and then secondarily by using a Package by Component approach. Components are independent collections of code that relate to a sub-domain. A Component in this context can be roughly equated to a Component in a Level 3: Component Diagram in the C4 Model.