Template WebAPI: One Solution Structure to Rule Them All
A part of the Template WebAPI series.
As of the the date of this post, the package structure is as so:
Solution Structure
The first distinction that I want to make about the project is the solution structure and how to organize your code.As of the the date of this post, the package structure is as so:
- project
- src
- clients
- template.Api
- core
- template.Domain
- template.Application
- template.Persistence
- test
project
This folder is used to store any project assets that may need to be edited by the developer, such as ignore files or deployment files (such as docker). Files that generally don't get touched by developers can stay outside of the solution.src
This folder contains all of the code used to execute the running application(s).clients
Clients are the executable running projects that combine integrate the software into a single application that will be used by consumers. There may be many clients, such as support systems such as cache services, running jobs, or other systems that support your main application.
template.Api
This is the WebApi project that integrates the application into a single web service that will interface with the rest of the system. The WebApi servers as the point of contact with other services, defines the contracts, and contains the configuration for wiring up specific dependencies.
core
Core contains the bulk of the application code that defines the behavior of the system.
template.Domain
This serves as the domain layer of the application. The domain layer consists of business defined entities that all other layers depend on. These entities should be as "pure" as possible, in that they only define what the business logic should interact, leaving the the future persistence layer to care about database implementation artifacts.
template.Application
This serves as the application layer of the application, where the application logic lives to define how the application should act. This layer only depends on the domain layer, in order to define what its working with, and defines what it needs in order to operate, such as data access or other external resources. This layer also defines what operations the application can do, which is used by the Api layer.
template.Persistence
This serves as the persistence layer of the application, used to define how we show intent to manage data. This is where we define which framework or technology we want to implement to access our data. This layer implements the interfaces defined in the application layer, such that it accepts what is easiest with the application layer, the domain entities, as well as returns the domain entities. Thus making it easier to switch out data providers as things change. This is especially powerful because if we do decide to split out ownership of some data from this service, then we can merely switch out the repository implementation rather than rip apart database specific implementation from our code.
test
This folder serves as a way to split out code that is not part of the code used to implement the actual application.
Comments
Post a Comment