JPA实体在域驱动设计中的责任

Question

I am wondering if JPA entity and DDD entity should be the same class? I can see in examples that it is a common practice, but doesn't it violate single responsibility principle?

Answer 1

I am wondering if JPA entity and DDD entity should be the same class? I can see in examples that it is a common practice, but doesn't it violate single responsibility principle?

You may want to review Classes vs Data Structures , by Robert Martin.

I would normally expect JPA entities to be "anemic bags of data"; they are essentially messages written in the past to be consumed in the future.

Domain Model Entities, on the other hand, are not anemic - they have direct understanding of how to mutate their own data structures in accordance with the rules of the domain in which they serve.

In the DDD book, Evans describes using the "factory" pattern to create an instance of a domain entity from raw data. That pattern fits equally well with creating a domain entity from a jpa entity.

The transformation in the other direction -- taking a domain entity and extracting from it the data you need to save, is not clearly addressed, but the mechanics are the same. You read data out of your domain entity, and write it into your jpa entity (whether or you writing into a new jpa entity, or updating one that already exists, will depend on the details of your persistence strategy).

You aren't guaranteed to make a mess if you try to make the two entities "the same", but there are definitely different concerns.

For example, our persistent representation of data is expected to have a life cycle that spans many releases, new versions of our domain model are supposed to be to work our previously stored data. At the same time, we should be able to change the data structures that we use inside the domain model freely. Semantically, it's the same information, but the pressures on structure and organization are very different.

Answer 2

I believe this to be common practice due to a level of convenience but it's not particularly clean design. In most cases it's coincidental that the JPA entities match, or are at least close enough, to domain objects.

JPA is an abstraction to the persistent data layer and its core focus is providing an object to relational data mapping. The JPA entities therefore really only represent object hierarchies of the data model.

It may well be that your domain objects consist of only elements that are represented and stored within a persistent data store and this would feel somewhat like duplication if creating both domain and JPA entities that contain the exact same data structures.

True domain objects live at the center of the application's architecture where all dependencies point towards them and this would also include the data layer. I would always recommend this approach purely as it clarifies the actual intent for the architectural boundaries.

Edit. To answer your second part of the question on SRP violation in JPA - it depends. The responsibilities (in SRP) do tend to match relational tables since we tend to logically group related data together (think Account table, or Contact table). This does fall down in JPA more often though when thinking about relationships (Employee -> Salary).