Most business domains have very interconnected Entities, sometimes up to the point where there is always a path going
from any Entity to any other. We can try to minimize the number of associations in our design, and this is a good practice
but it can lead to a translation loss between business and software. In a typical object model, it is difficult to
clearly see the boundaries of a change. This is particularly acute in systems with concurrent access such as Web
applications.
An Anemic Domain Model is something that can be found a lot of projects and, astonishingly, is often viewed as a good
practice. But as you may already have deduced from its name, it doesn’t sound like something desirable and certainly not
in DDD-oriented software.
Sometimes behavior doesn’t fit into Entities or Value Objects. Pure operations may exist in the domain and should therefore
be modeled as such. Domain-Driven-Design propose the Service pattern to model these operations.
Modeling business concepts with objects may seem very intuitive at first sight but there are a lot of difficulties
awaiting us in the details. To clarify the meaning of model elements and propose a set of design practices, Domain-Driven
Design defines three patterns that express the model: Entities, Value Objects and Services. This chapter will focus
on Entities and Value Objects, leaving Services for their own chapter.
While you can do plain JPA by injecting EntityManager anywhere, it is better to define an architectural layer where you encapsulate persistence-related operations. In the business framework, persistence is confined to Repositories.
JPA repository Default JPA repository The JPA add-on will provide a default JPA repository implementation for every aggregate that does not have a custom one. Two cases may occur:
You don’t have any custom repository interface an particular aggregate.
To go beyond what is described in this documentation, we recommend a few books which will help you to better understand DDD, independently of the business framework.
Domain-Driven Design community This is a major online resource about Domain-Driven Design with a lot of contents to discover and learn about it.
Online community Eric Evans: Domain-Driven Design Reference This book by Eric Evans is a summary of patterns and definitions of Domain-Driven Design.
Now it is time to spice up our «Hello World» application with some business code. With SeedStack business framework, it is easy to write clean and maintainable business code.
Domain-Driven Design Domain-Driven Design is a software approach built on the idea of solving business problems through code. This is done by focusing on the heart of the business logic, to distill a design that can solve business problems.
The business framework helps with the implementation of that domain model.
As described in the assemblers page, you can inject assemblers and use them
directly. However, the business framework provides a Domain-Specific Language (DSL) to do common Aggregate/DTO mapping
operations.
Domain-Driven Design itself can be successfully applied in variety of software architectural styles. Some are very broad and tend to define every aspect of the system, others are more focused and try to address a specific demand.
The business framework itself can adapt to several architectural styles. This documentation will focus on the traditional layered architecture from the Eric Evans DDD book, improved by the usage of the Dependency Inversion Principle.
We recommend a well-defined package layout for organizing your business code according to the software architecture described above.
The domain The root package for the domain layer is:
[base.package].domain The domain can be composed of several sub-domains that can be specified as sub-packages:
[base.package].domain.subdomain1 [base.package].domain.subdomain2 ... The domain package (or each sub-domain package if relevant) contains:
A model package containing aggregates, each in its own package. An aggregate package contains The aggregate root along with other related entities and value objects, The factory interface if any, The repository interface if any, The aggregate policies if any.
Pagination is a common need in business applications. The business framework provides a paginator
Now that we have a domain model, we would like to use some persistence with it. In Domain-Driven Design, persistence is done with Repositories which work on whole aggregates.
We need some data first! To be able to test this, we need some sample data. A class implementing LifecycleListener will provide the opportunity to insert data at application startup.
In the package infrastructure, create a SampleDataGenerator class:
package org.generated.project.infrastructure; import javax.
In the business framework, you always inject dependencies by interface not by implementation class. For each injection point, two situations are possible:
If only one implementation exists for a specific interface, it is injected without ambiguity. If multiple exists for a specific interface, the injection point should be qualified to select the implementation to inject. This done by putting an qualifier annotation along the @Inject annotation. Built-in qualifiers SeedStack provides several built-in qualifiers.
This tutorial will guide you step-by-step in building a full application with SeedStack business framework.
Domain-Driven Design is a software approach built on the idea of solving business problems through code. This is done by focusing on the heart of the business logic, to distill a design that can solve business problems.
The business framework helps with the implementation of that domain model. It also provides default implementations and helpers to quickly address related needs like model mapping or pagination.
What is DDD ? Domain-Driven Design (DDD) is a term coined by Eric Evans in his book «Domain-Driven design», published in 2003.
Aggregate design
Aggregate design
