Field-driven design in my eyes (RPM)

Original address: http://www.cnblogs.com/richieyang/p/5373250.html

Fortunately participated in a number of field-driven projects, read a number of articles, but also saw some nondescript architecture, feel the field drive has a further understanding. So talk to the guys today about domain-driven design, but also for some of the areas that want to drive the design but there is no place to start, or some are practicing but can not say that the field-driven design in the end good friend some direction. Of course, the theme of "field-driven design" has never been controversial, so you can speak freely.

Why use domain-driven design?

The title of Eric Evans's domain-driven design: The software's core complexity approach is a way of addressing the core complexity of software. That means the software business is becoming more and more complex, and domain-driven design can make things easier. The reality is: the threshold of domain-driven design is very high, the lack of a very deep object-oriented coding ability is almost impossible to practice success.

Is this argument contradictory? Martin Fowler a powerful explanation in POEAA's book:

In addition to the domain-driven architecture, the three-tier architecture can be summarized as a data-centric architecture, with black thick solid lines in the diagram;

The field-driven design is a green thick solid line in the diagram.

• When the software is in the early stages of development, data-driven architectures are very easy to use, but as business grows and projects advance, software development and maintenance becomes more difficult.
• Domain-driven design is a relatively difficult place to start at the beginning of the project, but as business grows and projects advance, software development and maintenance becomes more difficult.

This image illustrates the difference between domain-driven design and the traditional software development model to address complexity in software development processes.

What is the core of domain-driven design?

As the name implies, the core of domain-driven design is the domain model , which can be generally understood as the first to find the domain model in the business, the domain model as the center-driven project development. The essence of domain model is that object-oriented analysis is the abstraction of things, and a domain-driven architect must be a master of object-oriented analysis.

In object-oriented programming, we pay attention to encapsulation, design low-coupling, high cohesion class. For a software engineering, it is not enough to simply design a class, and we need to design the tightly connected business as a domain model that hides some of the details inside the domain model, so that the relationship between the domain model and the domain model becomes simple. This idea effectively reduces the complexity of the coupling between the business.

For the data-centric architecture model, the relationships between tables and tables are complex:

is the domain model: only large-grained interfaces and interactions exist between domains and domains:

Early friends of DDD must not miss Eric Evans's "domain-driven design: The software's core complexity response", a book of Great fame and the first choice for many people in the field-driven design, which mentions some of the concepts in domain-driven design: Repository, Domain,valueobject and so on. But beginners may come to the wrong conclusion: Some people mistakenly think that adding ***repository,***domain,***valueobject into the project architecture becomes the DDD architecture. Adding these concepts to the project without realizing its essence is at best a three-tier architecture, whereas for a master of object-oriented analysis, domain-driven design can be implemented without using these concepts.

Taking repository's design as an example, I often see in some articles the definition of irepository as:

12345678

public interface Irepository<taggregateroot> {       taggregateroot Get (int id); &NBSP;&NBSP;&NBSP;&NBSP; void Remove (Taggregateroot aggregateroot); &NBSP;&NBSP;&NBSP;&NBSP; void Update (Taggregateroot aggregateroot);  &NBSP;&NBSP;&NBSP;&NBSP; //what ' this? &NBSP;&NBSP;&NBSP;&NBSP; taggregateroot Where (Expression<func<taggregateroot, bool>> filter);

12

//…}

The domain-driven design is based on the domain model, which indicates that in the Irepository<taggregate> interface, only get (int id), Update (Taggregateroot aggregate), Remove ( Taggregateroot aggregate) These three interfaces make sense. The Where (expression<func<taggregateroot,bool>> filter) definition exposes you to a single-table operation, without a query for the domain model.

And for iuserrepository such a slightly specific interface definition:

1234567

publicinterface IUserRepository : IRepository<User>{    //What‘s this?    List<Rule> GetRules(int id);    //....}

A iuserrepository is still a repository, and he can only operate on the user aggregation root. Method list<rule> getrules (int id) will return this repository to its original shape, which is no longer a repository, this is a dal.

The right way to implement:

1234567891011121314

public class User:AggregateRoot{    private List<Rule> GetRules()    {        return null;    }        public void ApproveRequest(Request request)    {        var rules = user.GetRules();        //......        //如果有权限就批准      }}

This code embodies the user as a domain model, he has his own responsibilities and capabilities.

How do I start to practice domain-driven design?

As stated throughout this article, domain-driven design focuses on the analysis of domain models and the abstraction of things, never mentioned how data accesses this topic, it is intended that the domain-driven design, we do not care about how data access, how to write LINQ high efficiency, using lazy loading or include, These implementation details will take you into the traditional three-tier architecture model.

In domain-driven design, the domain model is first designed, and then the domain logic is written, and the database is simply a tool for storing data. Using database first is not called domain-driven design, it is obvious that you design the table structure, so it should be called data-driven design more accurate. Not to mention the unique technologies of the database, such as triggers, stored procedures, etc. In addition to storing data, the database is the domain logic for all the rest of the logic.

We might as well be familiar with the hospital outpatient procedures for example, to see how to start the practice of field-driven design:

For the moment, we think that an outpatient procedure is a complete domain model, when you want to forget about the database and not how the table structure is designed, but rather abstract the domain model:

1234567891011121314151617181920212223242526272829303132333435363738394041

public class OutPatientProcess:AggregateRoot{    public Registration _registration { get; private set; }//挂号单    private List<Examination> _examinations;    public IReadOnlyList<Examination> Examinations => _examinations.AsReadOnly();//化验单    public Prescription Prescription { get; private set; }//处方    public DateTime ConsultaionTime { get; private set; }//接诊时间    public Doctor Doctor { get; private set; }//接诊医师    //开始一个门诊治疗过程    public void StartProcess(Registration registration)    {        _registration = registration;        InquireSymptoms();        WriteOutExamination();        WritePrescription();    }    //询问病人病情    public void InquireSymptoms()    {           }    //开立化验单    private void WriteOutExamination()    {        _examinations.Add(new Examination());    }    //填写处方    private void WritePrescription()    {            }}

Let's not talk about whether this model fits the real scene, but this example takes you to the first step in domain-driven design, and this example shows you that software development is not designed to be a database first. Once you have written all the domain logic, consider persisting the class in the database. In my eyes, the database is just a thing to keep the data, don't put him in the code too early. This emphasis has been placed on a number of points that affect your ability to practice DDD successfully.

CQRS Architecture Outlook

That said, but since you're using a relational database, someone will have to talk to you about how performance optimizes such topics. This is also the traditional orm+ relational database implementation domain-driven design of the mishap, especially when your domain model scope design is too large, meaning that the operation of repository each time to correlate a bunch of tables out, especially someone design data like to abide by the nth paradigm this basic is not (without belittling the meaning of adhering to these paradigms, only this design of the database +orm will produce more associations, the relative design for the table structure redundancy design, in favor of the ORM to improve performance), have to say the last due to the storage performance of the database, we once again put the database into the scope of consideration.

The solution to this problem is the CQRS architecture, the query side of various caches and nosql, by the way the search engine is also used, so that your software to dash up. This architecture Decouples database operations, and you have virtually no opportunity to work with databases and also address data storage performance issues.

This evolutionary process also unlocks some doubts about why the design patterns have been learned since the beginning of the code, but have never had a chance to use them. Because the code you write is coupled with the "cancer" of the database all the while, and database operations are doped into your code as an implementation detail, so domain-driven design is born, are you ready?

Classification:. NET good text to top concern my collection this article Richiezhang
Follow-20
Fans-399 honors: Recommended blog + add attention

Field-driven design in my eyes (RPM)