A preliminary study of C # Advanced series--DDD Field drive Design (i.)

Preface: There is almost half a month did not write something, feel so very sorry myself. Today, I read a blog post that reads: The more busy man, the more time they have to write blogs. Oh, seems a bit reasonable, Bo Master in order to prove himself is also busy man, this does not come to learn under the DDD so a sound tall on things. The previous introduction of the next MEF and AOP related knowledge, after the plan to share AutoMapper, warehousing mode, WCF and other things, but each preparation to write something, it was to write the demo baffled, such as storage mode, used its friends should know, If your project is not in accordance with the structure of DDD to introduce the design of warehousing, then it will become very "chicken", the bad will be very painful, have seen this blog in the garden of the Daniel, you have suffered miserably, the Entity framework never need to write repository design mode The article's friends should remember, not only the author of the article, many friends in the comments also mentioned the use of it's uncomfortable. Bo master project also encountered similar problems, although the introduction of warehousing model, but because there is no structure, the storage interface and implementation of the unified in the data access layer, resulting in the later code more difficult to maintain the write, completely feel the benefits of warehousing. So bloggers feel that simply sharing the storage model is easy to make the reader into the "model and mode" of the misunderstanding, coupled with the recent period of time to see the domain-driven design: Software core complexity of the way to deal with. Eric.eva "This book and the blog Park Daniel Dax.net's DDD series, so intends to share a demo to illustrate the storage mode, AutoMapper, WCF and other knowledge points.

I. Basic concepts of domain-driven design

According to the domain driven design: The software core complexity response. Eric.eva, the domain model is the core of the common language of the software project, and is the common language rule that the domain experts and developers abide by, so the importance of modeling is not much to be said in DDD, so it is necessary to understand the domain-driven design so as to understand the division and establishment of domain model. First look at some of the more important concepts within DDD:

1. Domain model: The domain model differs from the data model by describing the classes in the domain and the relationships between them . From the perspective of domain-driven design, a database is nothing more than an external mechanism for storing entities, it is a technical aspect. The data model is mainly used to describe the persistence of domain model objects, it should be a domain model, there is a data model, the domain model needs to be a mapping to produce the corresponding data model, from this point, the latest EF code First is a good embodiment. Domain model objects are divided into entities, value objects, and services.

2, Entity: In the domain-driven design, the entity is the object that needs to distinguish the individual in the model. Entities and entities inside the entityframework are not a concept, EF entities are data entities and do not contain the behavior of objects. In terms of the blogger's understanding,the entity inside the DDD concept is a combination of entity data (model of EF) and behavior .

3. Value object: An object identified by the object's property value, which combines multiple related attributes into a conceptual whole. A value object is just one sign less than an entity compared to an entity. The design comparison of value objects is controversial, we remember the difference between the value object and the entity: (1) The entity has a unique identity, and the value object does not, (2) The entity allows the change, and the value object does not allow the change, (3) The method to judge the equality of two entities is to judge the identity of the entity equal, The criterion for judging the equality of two value objects is that all the property values within the value object are equal;

4, Aggregation (and aggregate root): aggregation represents a set of domain objects, including entities and value objects, to represent a complete domain concept. Each aggregation has a root entity, which is also called the aggregation root. As a simple example, a computer contains a hard disk, CPU, memory, and so on, a combination of which is an aggregation, and the computer is the aggregate root of this combination. Bo Master think about the division of knowledge is still very large, need to accumulate in practice slowly. The same entity, in different aggregations, it may be the aggregate root, or it may not be, depending on the actual business decision. The aggregation root is the principal of the domain concept as expressed by the aggregation, and when an external object accesses an entity within an aggregation, it can only be accessed through the aggregate root, not directly .

5, Domain Services: Bo Master Understanding, Domain Model advocates rich domain model, that is, the domain logic as far as possible to write in the domain entity, that is often said "congestion mode", and for business logic, preferably in the form of services to provide. As for the definition of domain logic and business logic, this should be determined according to the actual situation. In short, Domain Services are used when dealing with bad definitions or certain mutable logic in domain models. Pending verification!

6, the factory, warehousing and other concepts remain in the demo inside the description.

Ii. Field-driven design start Tour 1, Project layering

Domain-driven design divides software systems into four tiers: infrastructure, domain, application, and presentation. Take a look at the layering in the book:

In fact, in the Dax.net series, this picture illustrates this architecture

2. Project Structure

Bloggers intend to use the Authority system case to illustrate the domain-driven design of the project architecture. The project is divided strictly according to the performance layer, the application layer, the domain layer and the infrastructure layer.

Presentation layer: An MVC Web project that is responsible for UI rendering.

Application layer: A WCF service that coordinates calls to the domain layer and provides the required interfaces to the UI layer.

Domain layer: Defines domain entities and domain logic.

Infrastructure layer: Some common technologies, such as AOP, MEF Injection, generic tool class, DTO model layer, why there is a DTO model layer, DTO is a pure data model for UI presentation, it does not contain entity behavior, is a model of anemia.

The entire project is called in strict accordance with the DDD design, the UI layer through the WCF service calls the application layer of the WCF interface, the WCF service through the storage calls the interface inside the domain layer, the infrastructure layer throughout the other layers, in the required projects can be referenced in the infrastructure layer inside the library.

3. code example

Next, the blogger, based on his understanding, uses this architecture from scratch to write a simple rights management system. Because it is a domain-driven design, the focus of the article is on the domain layer, where the project uses the model first of EF to design the entity and then generate the database.

3.1 First to look at the table structure

First, the corresponding table entities are built, and then the database is generated according to the model

The resulting SQL statement is executed and the corresponding table structure can be obtained.

3.2 Division of the aggregation

In the domain layer we create a new Basemodel with three classes inside.

These three classes ientity, Iaggregateroot, aggregateroot respectively define the interface of the entity, the interface of the aggregation root, and the abstract implementation class of the aggregation root.

    // used as a generic constraint that represents a domain entity    that inherits from the interface  Public Interface ientity    {    }

    /// <summary>    /// The aggregation root interface, used as a generic constraint, constrains the domain entity as an aggregate root, indicates that the interface is implemented as an aggregate root instance, and because the aggregation root is also one of the    domain entities, implement the IEntity interface /// </summary>     Public Interface iaggregateroot:ientity    {    }

 // <summary>    /// an abstract implementation class for the aggregation root that defines the public properties and Behavior    of the aggregate root /// </summary>     Public Abstract class Aggregateroot:iaggregateroot    {            }

The purpose of defining an interface here is to define a generic constraint for the entity and aggregate root, which is used to define the common behavior of the aggregate root, and so far these interfaces and classes are empty, followed by the logic that is added to the project's requirements.

In EF, the properties of the entity are generated by the edmx file, and the domain model argues for the congestion pattern, so the behavior of the entity is added to the EF's entity model, so we use the partial class to define the behavior of the entity in order not to change the code of the EF-generated entity. Let's look at the code below the Model folder

     Public Partial class Tb_department:aggregateroot    {        publicoverridestring  ToString ()        {            return Base . ToString ();        }    }

     Public Partial class Tb_menu:aggregateroot    {    }

    /// <summary>    /// because this table is not directly manipulated, the Tb_menurole entity does not have to be an aggregate root,    but only as a domain entity /// </summary>     Public Partial class tb_menurole:ientity    {    }

     Public Partial class Tb_role:aggregateroot    {    }

     Public Partial class tb_userrole:ientity    {    }

     Public Partial class Tb_users:aggregateroot    {    }

We see that these entities, only Tb_menurole and tb_userrole, are not aggregate roots, and other entities are aggregate roots. Here I am probably divided into 4 aggregations:

Aggregation 1:tb_department Entities

Aggregation 2:tb_menu Entities

Aggregates 3:tb_users, Tb_userrole, Tb_department, tb_role These 4 are an aggregation, and the aggregation root is tb_users.

Aggregates 4:tb_role, Tb_users, Tb_userrole, Tb_menurole, tb_menu These 5 tables are an aggregation, and the aggregation root is tb_role.

Perhaps this branch has certain problems, follow up and then slowly correct.

Here, the division of the aggregation is basically finished, as to why to do so some constraints and design, because the warehouse can only be used to do the aggregation root, the next part of the storage will be described in detail.

DDD Profound, many of the views of the blogger personal understanding, may not be too mature or wrong, welcome to shoot Bricks ~ ~

A preliminary study of C # Advanced series--DDD Field drive Design (i.)