Template WebAPI: One Solution Structure to Rule Them All

A part of the Template WebAPI series.

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

Popular posts from this blog

Uncle Bob's Clean Architecture

Image
The basis of my current understanding of architecture comes from the brilliant mind of Robert C. Martin (Uncle Bob). You can find the original post through his blog , which I strongly encourage you to read. In this post I'll try to summarize some of the key points I've understood from his post. Clean Architecture Source Clean architecture is a design used to emphasize the structure and relation of your various code components to promote the idea of Dependency Rule , such that "source code dependencies only point inwards" . Clean architecture is able to promote this by defining that your software system consists of various layers , that can be organized in such a way that the layers point in one direction, and a dependency graph will not have circular reference. The reason this is important is because it allows you to keep closely code related, and increase clarity of how components fit into your system. Explaining the Layers We can really separate out this
Read more

C4 Model: Describing Software Architecture

Image
The point behind a presentation of Visualizing Software Architecture , by Simon Brown, was that we need to standardize the way software developers communicate with each other in respect to our discussions of software architecture. As part of Simon's consultation, one exercise he gave to software architects was a simple task to white board the architecture of a software system. The results he received varied immensely, and there was never a defacto standard format that he received from this exercise. When inspecting the feedback from the participants, the general answer was that it was easy to come up with the design, but difficult to properly put their ideas onto paper, or white board in this case. White Board Example, c4model.com Simon sought to start a movement by defining a set of organizational rules to help us describe our software architecture with a set of standard terminologies. His work has let to C4 Model , which stands for C ontext, C ontainers, C omponents,
Read more

Multi-Tenant Design: The Basics

Image
As your software system begins to grow and become a successful, you may find yourself at a place where you will want to monetize your software by allowing other companies to use it. One such design that will come in handy is called the Multi-Tenant design, and it allows you to license your software to other companies, allowing them to use your software system for through some contract. You manage the system, and they are merely an entity within it, a tenant. Source At its core, a multi-tenant design is driven by the idea that each tenant contains an identifier, which is then passed through with each request or action. By including this information, the system will know what behavior or data set to pull from. Traditionally the tenant identifier is GUID  that is transferred through HTTP requests as a HTTP header, x-tenant-id . The value is then kept within the thread context, and used to determine the configuration of a request, as well as the data it can access. Data should ei
Read more