CODEWITHSUNDEEP
c#javadesign-patternsarchitecturedomain-driven-design
Pingpong
Pingpong

Reputation: 8009

Domain model entities vs data entities, one or both in software architecture

**Update 2**

I have a project with a typical 3 layer structure(UI/Domain/Data layer). What is the pros and cons to have both domain model entities in domain layer and data entities layer.

The possibility of changing to different database is slim. What is the pros and cons of having only data entities in data layer as domain model entities? What is the difference if ORM is used (Is it good practice to have both entities when ORM (NHibernate) is used)?

Please fire your ideas, or links, articles, books.

Update 3

In what circumstances we should use both domain entity and data entity?

Upvotes: 3

Views: 2926

Answers (4)

user1342582
user1342582

Reputation:

You use data entities if your data schema does not map exactly onto your domain entities. For example, consider a telephone number. In your domain entity, it may be one single property whereas in the database it may consist of an area code field and a telephone number field.

Contrary to what some answers suggest, the data access layer DOES NOT hydrate your domain entities and DOES NOT have intimate knowledge of them. Instead, your domain layer asks your data access layer for data needed to reconstruct instances.

Upvotes: 2

Szymon Pobiega
Szymon Pobiega

Reputation: 3376

Using data entities with domain entities is a tricky thing to do and adds another not necessary layer of abstraction without adding any value.

You should either use full-featured domain model mapped via ORM or 'anaemic' data model (also mapped via ORM). Which one depends on your background, requirements and personal preferences.

In case of data model, you probably map directly tables to entities (one-to-one) without any complex stuff like inheritance hierarchy mapping. That's fine. The tricky thing is mapping 1:n relationships. With data model they tend to work well if you don't represent the 'many' side in object model. Why? Because both relation ends will easily be out of sync if you don't add custom code to handle these cases.

In case of domain model, you probably use repositories to fetch your aggregate roots.

There is exception to what I've written. It is legitimate to use both data entities and domain entities in CQRS architecture.

Upvotes: 1

Jim Barrows
Jim Barrows

Reputation: 3634

The domain model should exist in as many places as possible to maximize code reuse and understanding. The exception to this would when using the domain model is prohibitively expensive, in either time, memory or transportation costs.

Let's say the you have have a supplier for parts. This supplier supplies thousands of parts to you, so the one-to-many in this case might be huge, especially considering the web of classes each part might bring along. However, you need a list of parts from a specific supplier for a specific widget. In this case, you create a value object with the just the data you need.

This value object can be a copy of the supplier object, with only the parts you need, or it can be a completely new class representing only the data you need.

The typical use case for this might be displaying the data on a web page, and your transferring the data via json.

Upvotes: 0

Dmitry
Dmitry

Reputation: 17350

Assuming your question is about DDD. In a typical DDD scenario, Domain entities are 'hydrated' by Data layer (which is often thin because it uses ORM). In order to hydrate Domain entities, Data layer has to have intimate knowledge of the domain. If you use ORM than you most likely not need separate 'data entities', ORM knows how to reconstitute your Domain objects. Hope this helps.

Upvotes: 1

Related Questions