Domain-driven design case: Tiny Library: business logic and System Structure

Previously, I released a practical case of domain-driven design: tiny library. This chapter describes the business logic and system structure design implemented in this case.

 

Business Logic

Tiny library's business logic is very simple, mainly as follows:

1. Any user can add books in the library (for simplicity, the books cannot be modified or deleted) or view the detailed information of the books.
2. Registered users, that is, readers, can borrow books, return books, view the list of books they borrowed and borrow information

Due to limited space, I will not discuss the case operation process here. Readers can download it by themselves.Source codeAnd then compile and run it in Visual Studio 2010.

 

System Structure

Because it is a domain-driven design, the system hierarchy in this case is slightly different from the traditional hierarchy. There are four layers: presentation layer, application service layer, domain layer, and basic layer. The presentation layer adopts ASP. net MVC Framework implementation; The application service layer is a WCF Service; the domain layer uses the Entity Framework and the apworks application development framework developed by myself; the infrastructure layer provides specific implementation for the entire application, such as IOC, caching, specifications, and repository. The entire system architecture can be described as follows:

 

It should be noted that there is a bidirectional dependency between the domain model and edmrepository in the domain, so I annotated it with yellow comments on the edge. In fact, the domain model only depends on the repository interface, while edmrepository is a warehousing Implementation Method Based on the Entity Framework. It implements the irepository interface and also relies on the domain model, to obtain access to the aggregation root. The key step is that the tiny library uses dependency injection to inject edmrepository into the domain model. Therefore, the domain model does not depend on the specific implementation method of warehousing, ensuring the purity of the domain model layer. Domain-driven designCommunityMany of my friends have questions about this issue. Tiny library is a good case to answer this question.

 

Visual Studio 2010 Solution Structure

Tiny library contains six projects in the Microsoft Visual Studio 2010 solution: tinylibrary. design, tinylibrary. domain, tinylibrary. repositories, tinylibrary. services, tinylibrary. webapp and tinylibrary. webapp. tests. As follows:

2. Tinylibrary. Design: Some design drawings of the project, including the architecture diagram above. It is generally useless (note: the tiny library solution of the first version does not contain this project, but it does not affect reading and learning)
4. Tinylibrary. Domain: The domain model project, including the domain model and business logic of tiny library, is also the core of this case. In order to design the domain model in a visualized way and use Microsoft technology to implement the case, the project uses Microsoft Entity Framework as the modeling tool.
6. Tinylibrary. Repositories: A specific implementation project of warehousing. It references the tinylibrary. Domain project, and references the apworks component to implement the irepository interface. This project only includes the warehousing implementation for the Entity Framework, and also implements the repository transaction context object.
8. Tinylibrary. Services: WCF Application Service Project, which occupies port 3722 and is used to interact with the presentation layer. The interaction uses data transferring objects (DTO) to implement a group of data contracts located under the dataobjects directory. From this project, we can see that DTO does not correspond to entity/aggregateroot in a one-to-one manner. Although in tiny library, it looks like an entity/aggregateroot corresponds to a data object, but you can read it carefully, the data in these data objects is inconsistent with the object states in the corresponding entity/aggregateroot. This is based on the applicationProgramDepends on your needs.
10. Tinylibrary. webapp: Main program in this case: an ASP. NET web application, which is based on the ASP. Net MVC Framework and provides the user interface and interactive interface
12. Tinylibrary. webapp. Tests: Tinylibrary. the single test project of the webapp project. In this case, it is used to create ASP. net MVC project is automatically generated. I did not write or modify any test case, so I can directly ignore this project.

 

Starting from the next lecture, I will introduce the implementation process of tiny library in detail. This process is not a step-by-step instruction on how to create a project, how to code it, but an introduction to the practice of domain-driven design under Microsoft. NET technology. These contents will include: Implementation of Domain Models, warehouse design and implementation, WCF Service and DTO, Asp.. Net MVC integration, domain-driven design case Q & A, and apworks Application Development Framework introduction. Coming soon!