26 | architectural overview of the project: the definition and application of hierarchical dependencies
From the beginning of this section to enter the micro-service real part
Hierarchical structure and application of this section mainly on projects
Here in layered application defines four levels:
1, the domain model layer
2, the infrastructure layer
3, the application layer
4, shared layer
We can look through the code
Source link:
https://github.com/witskeeper/geektime/tree/master/microservices
Sharing layers build a total of three projects:
1, GeekTime.Core: simple carrier base of the main types, such as abnormal or helper classes
2, GeekTime.Domain.Abstractions: abstraction layer, abstract art refers to the domain model can define the base class or interface, the interface field event, art event processing interface, as well as interfaces Entity and Entity base class
3, GeekTime.Infrastructure.Core: core infrastructure, means of storage, as well as EFContext define some shared code
In fact these packages can be shared in different projects inside, so the recommended practice is to put these codes are stored by private NuGet warehouse and other projects can be used to package a direct reference to NuGet
Domain model layer is the definition of domain model where there will be different polymerization, as well as the field events, different polymeric Here is the domain model
Infrastructure layer, and some shared code storage layer, where only defines the storage layer to achieve, including the EF DomainContext, as well as Order of storage layer, User storage layer, also defines a mapping between a domain model and database relations, is to define this in the following directory EntityConfigurations
The application layer is divided into two, a project is API layer, API is used to carry Web application or the Web, is a further background task, the task is to execute special Job, as Job host runs, it can be a console application
In the Web tier, Web API layer, can be divided into several key directory Application, Controllers, Extensions, Infrastructure
Infrastructure layer will put some some code related infrastructure facilities to interact with the authentication cache and the like
The main enhancement layer service code is the code register into the container and the intermediate configuration, i.e. two extension method, a ServiceCollection is an extension of one of the extension of ApplicationBuilder
Controller layer is mainly used to define the Web API, the front and rear ends of this layer is defined interaction interface
CQRS application layer using design patterns, is the separation of command and query functions, the commands in a directory, query in a directory, the same directory where there are two event handlers, one domain model, field events treatment is a process of integration events
Look again at the dependencies between the layers
Shared layer is actually not dependent on any level, it stores the shared code that is shared each project
GeekTime.Core, GeekTime.Domain.Abstractions is not dependent on any project, and GeekTime.Infrastructure.Core relied GeekTime.Domain.Abstractions, to achieve the storage, such as storage interfaces will depend IAggregateRoot
public interface IRepository<TEntity> where TEntity : Entity, IAggregateRoot
FIELD model requires it inherits the model, and implements the interface polymerization of a root, a root of the polymer indicates that it is
public class Order : Entity<long>, IAggregateRootField events need to achieve a field event interface
public class OrderCreatedDomainEvent : IDomainEvent
Infrastructure layer is a separate set of programs to achieve some warehousing, storage and defines an Order of
public interface IOrderRepository : IRepository<Order, long>Order also defines the implementation of storage
public class OrderRepository : Repository<Order, long, DomainContext>, IOrderRepository
{
public OrderRepository(DomainContext context) : base(context)
{
}
}Here you can see the definition of warehousing actually depends IRepository storage infrastructure layer inside the shared code, so that you can reuse the code storage layer, so that the definition of OrderRepository will be relatively simple, some implementations can be complex with the Repository
public abstract class Repository<TEntity, TKey, TDbContext> : Repository<TEntity, TDbContext>, IRepository<TEntity, TKey> where TEntity : Entity<TKey>, IAggregateRoot where TDbContext : EFContext
{
public Repository(TDbContext context) : base(context)
{
}
public virtual bool Delete(TKey id)
{
var entity = DbContext.Find<TEntity>(id);
if (entity == null)
{
return false;
}
DbContext.Remove(entity);
return true;
}
public virtual async Task<bool> DeleteAsync(TKey id, CancellationToken cancellationToken = default)
{
var entity = await DbContext.FindAsync<TEntity>(id, cancellationToken);
if (entity == null)
{
return false;
}
DbContext.Remove(entity);
return true;
}
public virtual TEntity Get(TKey id)
{
return DbContext.Find<TEntity>(id);
}
public virtual async Task<TEntity> GetAsync(TKey id, CancellationToken cancellationToken = default)
{
return await DbContext.FindAsync<TEntity>(id, cancellationToken);
}
}We have achieved some basic methods CRUD methods
Implement database access, inherited EFContext own definition, EFContext as a shared code reuse in various projects inside
public class DomainContext : EFContextAnother more particular object of the transaction, request context object is used to manage the entire application in the transaction, thus avoiding manually to transaction processing, to simplify the code
public class DomainContextTransactionBehavior<TRequest, TResponse> : TransactionBehavior<DomainContext, TRequest, TResponse>
{
public DomainContextTransactionBehavior(DomainContext dbContext, ICapPublisher capBus, ILogger<DomainContextTransactionBehavior<TRequest, TResponse>> logger) : base(dbContext, capBus, logger)
{
}
}
The application layer relies infrastructure layer, infrastructure layer and layer-dependent areas
The application layer is the fact that one of the layers assembled together, it is a host application, the relationship between the layers coordination, and assembly code is implemented here
in conclusion
Domain model layer to focus on business design, it does not depend on other layers, it is relatively independent
Storage layer is only responsible for infrastructure access domain model, which bearer service logic of the code responsible Ho
CQRS recommended model to design an application, the application of the code structure more reasonable, in the case of team and project expansion, maintainability engineering will not drop sharply
Web API is for a front end interface interaction, to avoid dependence domain model
Recommendations designed to share code share package, use private warehouse to distribute and manage NuGet
This work is Creative Commons Attribution - NonCommercial - ShareAlike 4.0 International License Agreement for licensing.
Welcome to reprint, use, repost, but be sure to keep the article signed by Zheng Ziming (containing links: http://www.cnblogs.com/MingsonZheng/), shall not be used for commercial purposes, be sure to publish the same work based on the paper license modification .
If you have any questions, please contact me ([email protected]).