first of all, the previous several cases of
DDD project failure, in fact, can not be considered a failure, but did not understand the idea of
DDD .
before the
DDD is built on the data layer, first of all the data table corresponding to a data entity, each data entity by the generic DAO Management, DAO is also inherited by the data context to implement the transaction, which constitutes the data layer, the business code is written in DataContext.
data layer: dataentity <-datamapper<dataentity> <-DataContext
building a domain layer of "seemingly" ddd on top of such a data layer, first, the domain object inherits the data context to enable serialization and dirty-read validation, and the aggregation root inherits the domain object for cascading updates, lazy loading, and managing associations between domain objects. Finally, the aggregation root is managed by the warehouse object that implements the LINQ query, which is the domain layer at that time.
domain layer: DataContext <-Entity <-rootentity <-Repository
This framework has been used for about 1 years, and in the process of using it, it has been found that
DDD has not brought any benefits in addition to increasing the complexity of the project.
it was not until a while ago that I realized that the domain layer built on top of the data layer was a complete mistake, that the domain layer should be at the bottom of the entire project, without inheriting interfaces such as Ientity,irepository, and it was these interfaces that kidnapped the domain model.
================== Split Line ==================
The redesigned domain layer was finally completed today, at the bottom is still the data entity, the original generic DAO and DataContext all moved to the crosscutting layer, in a similar way to the domain layer to provide services.
above the data entity is a value object, and the value object is built entirely according to the domain requirements. There is also a thin layer of data transformation services between data entities and value objects that transform database-oriented data entities into domain-oriented value objects.
data tier: dataentity <-> Data Transformation Services <-> valueobject
above the data layer is the domain layer, a domain object holds several value objects, the domain object load maintains its own state, and the domain object is at the same level is the domain service, the domain service prefers to deal with the business logic, on the two have the storage object, only is responsible for the query.
domain layer: entity/service <-Repository
built beyond the data and domain layers, the crosscutting layer provides lightweight data services such as transaction management, object
caching , and datamapper of singleton patterns. These services are provided in a using way, i.e. they can only be used within a small range of function blocks and automatically destroyed after use.
Cross -cutting layer: Eventmanager/cachemanager/datamanager, etc.
================== Split Line ==================
Now the domain layer has been at the bottom of the entire project, Valueobject is completely in accordance with the needs of the domain of the object of the building, use it handy.
today in a large project after the practice found that can not refer to the UI design, not reference to the prototype design, only according to the requirements of the specification design domain structure, the design after the completion of the domain model is incredibly in line with the needs of the UI and prototyping.
such a development process also seems to be in line with the concept of TDD, interface first, then the test, then the function, and finally the UI. The original data layer is now scattered over 3 parts:
1, remove the weight of the ORM functions, such as cascading updates, delay loading, even table query, etc.
2. Basic single-table persistence move to the crosscutting layer, note the bottom dashed line, and now data persistence is done by sending messages to the data store through the data entity.
3, cache management, transaction management moved to the crosscutting layer, now directly
cache the domain object, instead of
caching the data entity
In other words, there is no data layer in the traditional sense, data storage is through the message mechanism to change the operation of Dataentity to the persistence service, the persistence service has very simple cud function, can connect to sql,nosql even XML file. This is exactly what this picture wants to say, and the storage layer does not need to interact with the database.
our habitual thinking, warehousing needs to accept a request, then query the database to get the data entity, and then convert the data entity to a domain object. People are always lazy, sometimes for the sake of convenience, data entities directly participate in business logic, or even return to the UI.
in this diagram, the domain layer, the application layer, the UI layer are not accessible to the data entity, Any manipulation of the domain object is converted to several Dataentity.change messages by the Data Transformation Service (the anti-corrosion layer), and the data store (persistent service) listens to these messages in a complex way and connects to the database.
This means that the domain layer only needs to modify the data, without needing to be concerned about the persistence problem.
http://www.jdon.com/44900
Excerpt from some DDD discussions from the forum
