DDD in the ddd~ concept

DDD in the concept

DDD: Domain-driven design, a complement to object-oriented analysis and design (Ooad,object Orient analytical Designs), provides a layered planning of the technical framework, with policy and type partitioning for each class. Domain model is the core of domain-driven, using DDD design idea, business logic is no longer concentrated on several large classes, but on a large number of relatively small domain objects, these classes have their own state and behavior, each class is complete independent, and with the real World business Objects form a mapping. DDD-based architecture design ensures system maintainability, scalability and agility, and has a clear advantage in dealing with complex business logic!

Changing the world of programming

The following information is copied from the http://www.jdon.com/ddd.html, well written, this is really a change in the programming world, and the traditional programming concept is completely different

In the past, demand analysis and system design are separate, as our national "system analyst" and "system Architect" Two titles examination, such fragmented results lead to the results of demand analysis can not be directly designed to program, and can be programmed to run the code is distorted requirements , Cause the customer to run the software only to find that very versatile is not what they want , and the software can not quickly follow the changes in demand .

DDD breaks this gap, puts forward the concept of domain model, unifies the analysis and design programming, makes the software more flexible and fast to follow the change of demand.

DDD is revolutionary: the domain model accurately reflects the business language, while the traditional layered architecture only cares about the data, which, in addition to simple read and write operations, has no business method and is likened to a blood loss model , and the domain model is a congestion model with a business approach. Where the hell is it?

See the domain model code, see the business requirements, no translation no conversion, to ensure that the software really achieve "copy non-aliasing."

The biggest benefit of DDD is that the first step in reaching a requirement is to consider a domain model rather than cutting it into data and behavior, then data is implemented using a database, behavior is implemented with services, and the first limb of the demand is separated. DDD lets you first consider the business language , not the data. The emphasis differs in that programming world view differs.

Features of DDD

• Layered architecture

1. Mature, clear layered architecture
2. Business mapping of domain objects to the world
3. Clear delineation of responsibilities

• Re-usability

1. The domain object is the core
2. Domain Object reuse: A complete business object description
3. Design exploits: Design based on domain objects rather than database-based

• Applicable occasions

1. Software development with complex business logic
2. High requirements for design and development personnel
3. Not suitable for normal curd operation
4. High maintainability and scalability of the system

Tiering for DDD system architectures

When the system is designed without DDD, it is generally divided into 3 layers, such as the data layer, the business layer and the presentation layer, and after the use of DDD, there are some changes in the layered way, first look at

1. Presentation layer: Also known as the web layer, UI layer, the general embodiment is the layout of the page, you can use the Web Mvc,web form,win form and so on to achieve
2. Application layer: Used to coordinate the application activity, which does not contain business logic, it does not preserve the state of the business object, but it saves the progress status of the application task
3. Domain layer: Contains domain information, which is the core of the business software that retains the state of the business object, delegating to the infrastructure layer the persistence of business objects and their state
4. Infrastructure layer: Is the basis for other tiers, which enables persistence of business objects, as well as the ability of the Web layer to reference this layer

Several core objects in DDD

Entities: This is not a simple poco entity, but an entity with business logic

Factories: Factory class, used to produce objects

Respositories: Persistent, which is itself a DAO (data access Objects) Access object

Services: A service layer that provides an operational interface for the upper layers, which is responsible for debugging and encapsulating object domain objects while providing various forms of service

OK, today this talk about here, just the concept, asking us to understand it, in fact, this understanding is indeed different from the previous architectural ideas, it is a different from the traditional way, we need to understand the heart!

Thank you for reading

Related articles

DDD in the ddd~ concept

ddd~ congestion model and blood loss model

ddd~ Infrastructure Layer

Ddd~microsoft the hierarchy chart in the Nlayerapp project

ddd~ field Layer

The use of ddd~unity in DDD

Source: http://www.cnblogs.com/lori/

DDD (Turn) in the ddd~ concept