Domain Driven design and spring

Original http://static.olivergierke.de/lectures/ddd-and-spring/

1. Introduction
This article is about the relationships and differences between the basic artifacts, concepts, and Java Web applications (mainly based on the spring framework) of domain-driven design.
The second part of this article describes how to map entities, aggregation roots, and warehousing to Java applications that use the spring framework
2. Field-driven design
Eric Evans's Field drive design is undoubtedly one of the most important books in the field of software design.
This book focuses on how to deal with the mapping of domains and software in software development-starting with the emphasis on domain common language (domain ubiquitous language), extracting models through language, and ultimately mapping to a working software.
We are already familiar with the software design pattern, which is a technical language for describing and refining class and class relationships. While DDD is a more general language for programmers and business communication, using DDD can eventually map code to models.

2.1 Basic Components
Components are some of the proper nouns in ddd, let's look at a

2.1.1 Clearance context (bounded contexts)
When modeling a domain, any attempt to model it as a whole is doomed to fail. Because the various stakeholders and their views on the field may be completely different, trying to build a single, unique model to meet all of the requirements is completely impossible and makes the system extremely complex.
Let's look at an example diagram that depicts a model that has been identified in the sales area

We distinguish the model elements into discrete models, and we can see the concepts of customers and orders, which are the core of different contexts.

Here, we have identified the core parts of the system's strategic dimension, which may involve the concept of a customer or an order, but often the different gauge contexts are not the same ones that are of interest to their properties. For example, the accounting context is typically interested in billing information and different payment options for the customer, while the shipping context's sole goal for the customer is to ship the address and then track the order. The order context may understand the product information through the customer's order entry, but in practice only covers the basic content of the commodity category (Translator Note: Product specifications, Product details These information order context is not concerned).

The model elements here may appear to be reflected differently in different layers of the system (translator: refers to the product and customer objects will exist in multiple realms, but different concepts). The modern software architecture even further, proactively reduces the complexity of individual systems through redundancy and eventual consistency, improves system resiliency, and improves overall development productivity (translator: CQRS and event-driven architecture)

2.1.2 Value Object
Represents a concept in a domain object-the value (as with his name), and the value object has no primary key without a life cycle. And he is immutable to ensure that it can be shared across multiple consumers. In Java, a string object is a good example of conforming to these features, but this is not quite the case for domain design, because he is too abstract. In general, credit card numbers and e-mail addresses can be well-constructed as value objects. A value object is often a property of an entity. Implementing a domain element as a value object can greatly enhance the readability of your code, as Dan Bergh Johnsson in his ddd power use of Value objects.
Because of the need to implement Getter, Equals (), Hashcode () methods, pure Java implementation Value objects are rather cumbersome (translators: in particular, there is no builder method). So many people do not want to do, value objects are often forgotten. Now you can use the Lombok tool to construct the processing value object conveniently.

2.1.3 Entity class
The core feature of an entity is that he has a primary key, compared to a value object. Two customers named Michael Muller may not be an instance, and we usually introduce a dedicated property to identify them. Another feature is that the entity class has its own life cycle in the problem domain. They are created, driven by domain events, undergo changes in various states, and eventually arrive at an end state (i.e. may be deleted, but not necessarily physically deleted). Entity classes typically involve other entities and contain value objects or basic types (like int boolean double in Java, etc.)

Entity class vs Value Object
is a domain concept actually an entity or a value object? This depends on the context. And in fact, a concept is different in the context of his type. For example, an address may be a property of a store, a value object. But when they are a customer's shipping and billing address, they are entity classes, because these addresses have a lifecycle that can be created, modified, and deleted.

2.1.4 Aggregation Root
Some entities play a very special role in the system. For example, an order consisting of an order item, the order entity can calculate a total price by traversing the internal order item unit price, and the order will take effect if the total price is higher than a set minimum value. This kind of entity usually we raise it to the aggregate root, the aggregation root like the meaning of the next
1. Aggregate root is responsible for the overall state of the aggregation, and changes to the state of the aggregation will cause the aggregation to migrate to a state or trigger an exception
2, in order to ensure this responsibility, warehousing (Repository) can only access the aggregate root. The state change of the entity class for the non-aggregated root must be triggered by the aggregation root. (Translator: Warehousing for the aggregate root and his Property object is the whole deposit, such as the acquisition of a car's wheels, we repository only have the method of acquiring vehicles, the wheel is accessed through the properties of the vehicle, not directly access the wheel object)
3, aggregation to form a natural consistency boundary, the application of other aggregation needs to be realized by By-id way.

2.1.5 Warehousing
Conceptually, a warehouse simulates a collection of aggregate roots and allows access to subsets of aggregates or to individual attributes. They are usually supported by some kind of persistence mechanism, but they should not be exposed to the client. Warehousing can refer to entities, but not in turn.

2.1.6 Field Services
Domain service is the implementation of a service that cannot be uniquely assigned to an entity or a value object method, and he also assumes the functional logic between the entity value object and the warehousing (translator: Domain Services typically take the approach of domain objects, Domain Services are stateless, such as transfers between two accounts). Although there are domain Services, the business logic is implemented as much as possible in entity classes and value objects. Because they can be tested more easily.

2.2 Domain-driven design in spring applications
The concept of domain and the mapping method of DDD concept greatly influenced the mapping of these concepts to code. To effectively write a spring-based Java application, you must differentiate between the Newables and Injectables objects.
As the name implies, the difference is in the way that developers acquire specific domain elements. An Newable object can be instantiated by operator, of course, this instantiation must be limited to as few places as possible, if the use of Factory mode is better, the entity and value objects are newable. Injectable is often a spring component, which means that spring will control its lifecycle, create instances, and destroy them. This allows the spring container to provide a transactional and secure infrastructure for instances of the service. The client obtains the instance through dependency injection, and both the repository and the service need to be injected.

The differences within these two groups are defined in the dependency direction from injectables to Newables. Generally speaking

• Value Object OBJECT-JPA @Emeddable note + corresponding equals (...) and Hashcode () method (Lombok's @value can be useful to help generate)
• Entity class ENTITY-JPA @Entity annotations + corresponding Equals (...) and Hashcode () method
• Storage repository-spring components, usually with spring's repository interface.
• Domains serve domain service-typically spring components, using @component annotations. If the service does not require transactional or secure support, it can also be directly new.

Not all objects in spring can be mapped into the classification of DDD. The remainder is generally divided into two groups:

Application Configuration Application config-object or configuration module
Technology adapter Technical Adapter-used to publish the logical layer of spring to the client through a remote access technology. In Web applications, Remote technology refers to HTTP, HTML, and JavaScript. In spring MVC, the Controller object will be responsible for translating remote objects (such as request, request parameter, payload, response, etc.) into local domain concepts and invoking service, entity classes, value objects, and so on.

3 Further Reading
Check guestbook and Videoshop to make sure you understand which classes implement which DDD concepts
Distinguish between these concepts (the primary key of the entity class, the invariance of the value object, the dependency injection of the service), and how the different characteristics are implemented.

Appendix
Appendix A:bibliography

• [DDD]-Eric evans-domain-driven design:tackling complexity in the heart of Software-addison Wesley. 2003.

• [Ddd-quickly]-Abel Avram, Floyd marinescu-domain-driven Design quickly. Infoq. 2006.

• [Power-of-value-objects]-Dan Bergh johnsson-power use of the value objects in DDD. Infoq. 2009.

http://newtech.club/

Domain Driven design and spring