Thinking with questions, Hello everyone!
A few days ago, I learned about the development mode of EF core: DB first (database first), model first (mode first), code first (code first).
Most of my contacts are DB first. If you understand, some open source background projects will have the latter two, because it is convenient for us to use the deployment background faster.
In the proposed layered [‘le ɪ D] Architecture [ˈɪ rk ɪ tekt ʃə R] pattern, — presentation layer, business layer and data layer. Evans analyzes and introduces two key changes.
1： Focus on the layer, not the tier. Layer is the logical separation between application components, while tier is physically different applications and servers.
2： The identified layers are divided into 4 layers: presentation layer, application layer, domain layer and infrastructure layer
Bottom down design, we are all around the data model development and design, the process and especially rely on the data model of the user interface and experience.
In a monolithic application, data is persisted from the bottom to the front, and then returned.
According to the layered architecture, we all know that from storage to the front end and from the front to the storage. Shouldn’t we consider splitting the application stack into two parts? Is it more effective to handle command stack and read stack independently for development? So NoSQL storage came, making the classic RDBMS system began to support XML and JSON. This is also the formal use of the command and query responsibility segmentation (cqrs) mode.
The above is a layered architecture model designed in combination with cqrs
Cqrs is not omnipotent. What matters is his thought.
Experienced developers know. It is difficult to create an ideal data model that combines the principles of a relational data model with the complexity of the views that end users actually need. If there is only one application stack, there can be only one persistence oriented data model, but this model needs to be adjusted to meet the needs of the front end effectively. In particular, when combined with some methodology (such as an additional layer of abstraction for Domain Driven Design), the design of the back end (business logic and data access logic) can easily get messy.
The above problems. CORS decomposes the design problem into two smaller problems. The new application architecture design solves the problem without imposing external constraints, making the design simpler. The advantage of having different stacks is that it’s easy to use different object models for fame and query. If necessary, you can use a complete domain model for commands and a custom common data transfer object for representation. These objects may be materialized from SQL queries, and multiple presentation frontends are required, and only additional read models need to be created. Global complexity is the sum of individual complexity, not Cartesian product.
1: Different databases
There are some problems in decomposing the stack into different stacks, the synchronization of the two stacks, and the data command writing can be read back uniformly? According to its own business, cqrs implementation can be based on one or two kinds of databases. If a shared database is used, the shared database ensures the classic acid consistency, and only needs to do some extra work on the ordinary queries in the read stack.
Performance and extension lines, consider using different persistence endpoints for the command stack and the read stack.
When to use cqrs?
This is a pattern. Cqrs architecture pattern is mainly designed to solve the performance problems of high concurrency business scenarios.
Composition of infrastructure layer
The infrastructure layer is everything related to the use of specific technologies, including data persistence O / RM framework (EF), external web services, specific security APIs, logging, tracing, IOC containers, caching, etc. The most prominent is the persistence layer of components, that is, the data access layer.
The persistence layer and cache layer external services are very mature and will not be discussed here.