The API project is currently a single project, consider moving it to an n-tier, onion/hexagonal, or package based architecture.
N-tier architecture here means that the project is separated into separate tiers (each being a project) and one tier can only reference the tiers directly above and below it. An example would be:
API can only reference
Service
ViewModels
Service can only reference
Data Access
ViewModels
Models
Mappers
Data Access can only reference
Models
Onion architecture is similar to n-tier, but any tier/project can reference any other tier that it requires.
Packaged based architecture here means that each "layer" of the tier is sliced away and created as Nuget packages, with each package referenced by and pinned to a specific version number.
High-Level Proposed Solution
The contents of the src/BookApi directory are split into separate projects
Each project delineates a boundary in the codebase
i.e. all Services are contained within a Services project
Unit tests (and to a lesser extent integration tests) are updated to point at the correct projects
Where necessary
Considerations
For simplicities sake, I would recommend either n-tier or onion/hexagonal architecture. This way we aren't clogging up development time with complexity. If it is decided, later in the project, that we need to move to a more microservices-based architecture then we can revisit the package based architecture. But for now, we are creating a BfF rather than a microservices-based application.
Requirements
The code within the main src directory is refactored, splitting it into multiple projects
Each project represents a delineated a boundary within the codebase
i.e. all Services are contained within a Services project, and all data access code is found in the DataAccess (or similar) project
All tests are updated to include references to the relevant classes and namespaces
All tests still pass
Test coverage percentage does not go down by a large amount
Description
The API project is currently a single project, consider moving it to an n-tier, onion/hexagonal, or package based architecture.
N-tier architecture here means that the project is separated into separate tiers (each being a project) and one tier can only reference the tiers directly above and below it. An example would be:
Onion architecture is similar to n-tier, but any tier/project can reference any other tier that it requires.
Packaged based architecture here means that each "layer" of the tier is sliced away and created as Nuget packages, with each package referenced by and pinned to a specific version number.
High-Level Proposed Solution
src/BookApidirectory are split into separate projectsConsiderations
For simplicities sake, I would recommend either n-tier or onion/hexagonal architecture. This way we aren't clogging up development time with complexity. If it is decided, later in the project, that we need to move to a more microservices-based architecture then we can revisit the package based architecture. But for now, we are creating a BfF rather than a microservices-based application.
Requirements
srcdirectory is refactored, splitting it into multiple projects