A simple CQRS architecture design and its implementation

First, why to practice the field-driven?

For nearly a year I've been thinking about a question: "How to design a loosely coupled, highly scalable, easy-to-maintain architecture?" ”。 The idea is that many of the projects I'm in touch with are database scripts that implement business logic. In the early days of the project, the brutal development seemed to be very efficient, but we all know that it is this kind of project that has dragged everyone into the abyss of overtime work. This system is poorly maintained, cannot be extended, and cannot write effective unit tests, and the quality is largely not guaranteed.

An architecture that fits my expectations is certainly not done by using a code-generation tool, which cultivates the yards as an outright non-ideological entity. A sought-after code farmer, keep away from the "architect" that will only let you use the code generation tool.

Since there are some deadly problems with database-driven development, we naturally think of domain-driven development (DDD). In the article "field-driven development in my eyes," I mentioned some of the ways that domain-driven design differs from traditional software development. These ideas seem simple, but real practice, the transformation of thinking is still a certain degree of difficulty.

Every colleague I've met in my career has been able to show that I'm good at discussing problems, some of them are more clear-minded, others are more specific, and talking to these people about the program will always be enough to inspire you. Domain-driven Development This approach needs to be integrated into the vitality of the idea that everyone can participate in the design, software development will become an interesting thing.

Second, using EF to practice domain-driven

I have tried to use pure EF to practice domain-driven development, and frankly, I can't practice success. I want to forget the database, but it's hard. Why do you say that? We know that domain-driven emphasis is on the domain model as the basic unit of thinking, such as a shopping process may be a domain model, I put aside the database, build the model. At this point, a demand, an interface need to be able to query a range of shopping records, there may be some complex conditions, this time my domain model does not support such a query, because I did not consider the table structure before the design, my domain model is not for the query design, So a query like this is prone to performance problems. So forget the database this proposition is difficult to achieve.

Third, why is there such a problem?

That's the problem I'm thinking about, is there a problem with domain-driven development of this software development approach?

The root cause of this situation is that "we impose a query on domain responsibility, long-term software development model too dependent on the relational database", the primary task of the relational database is to persist data, query is only part of his ability, for a long time we want to let the relational database storage of massive data, And you want to make the query more efficient. Obviously, our requirements for relational databases are a bit too much.

I think that's why Greg Young proposed the CQRS architecture, and when we removed the search and query responsibilities in the domain model, the problem was solved.

Iv. What are the difficulties of realizing CQRS?

Since CQRS is the best way to practice ddd, can we use CQRS? Referring to CQRS, I had to mention the two CQRS veterans of the blog Park, Dax.net and Netfocus, two of whom contributed their own CQRS framework, but I suspect that even their two great gods would not easily use the CQRS architecture in real-world scenarios. In my opinion, to really practice the CQRS needs the timing, geography, people and three.

1, the classic CQRS is through the event sourcing to achieve domain model restoration and query end synchronization, which requires the domain model design must be in place once, once the event is persisted into the production environment, then modify the design will bring great difficulty.

2, the developer requirements are very high, to establish such a team will need a long time running and training.

3, the use of CQRS DDD because of the design requirements are high, so in the early stages of development and can not quickly see the effect, which requires the company to tolerate, understand and support, this seems to be the most difficult to meet the conditions.

V. Realization of a simple CQRS scheme

After analysis, in order to successfully practice the domain driver, the query and command responsibilities must be separated, we still want to implement CQRS, but no longer through the event sourcing to achieve, thus reducing complexity. Here is one of my less-mature ideas:

1. Domain is persisted through EF.

2, each domain logic in the implementation will produce two fixed types of event,***createdevent and ***updatedevent.

3, due to the cancellation of the event Sourcing, so the complexity of the domain design is reduced, at this time the relationship data is equivalent to the latest snapshot.

4. Register the callback of the release event after the successful execution of EF unitofwork to ensure that the domain model persists successfully before the event is published.

5, the event is published to Duplex Servicebus, the duplex Servicebus contains a inmemory synchronization Servicebus and an asynchronous servicebus that supports Message Queuing.

6, the field after the event, the first inmemory synchronization Servicebus updated by the Redis implementation of Querymodel, to ensure that the interface will be refreshed synchronously, a single domain read will be achieved through Redis. The message is then sent to an asynchronous servicebus that supports Message Queuing.

7, the message into the message queue for the consumption of other subsystems, while updating elastic search, the interface of the complex search will be done by elastic search.

8, the system has been transformed into a loosely coupled, extensible, domain-based model of the distributed architecture scheme.

When the responsibility of querying and reading domain is distributed to elastic search and Redis, there is no external factor to interfere with the design of the domain model.

In addition, the whole system will not appear a SQL, let SQL this anti-human language to hell, if anyone else feel "must write sql,sql efficiency." You come, I promise not to kill you. O (^▽^) o

The current demo based on the above ideas is being implemented in steps, please pay attention. In addition, because of the limited level, the whole structure design inevitably has unreasonable place, welcome to put forward valuable suggestions.

Https://git.oschina.net/richieyangs/BookLibrary

A simple CQRS architecture design and implementation