Value objects in DDD

Question

I have Order and OrderType classes in my sale module, that OrderType class uses for some categorization goals and applying some business rules on Orders. each class has its own table.

I want to apply DDD techniques on my project. So, I think that the Order is an Aggregation root, but what about OrderType? Is it also contained in Order aggregation or is it a Value object? I think it will be a value object. Am I correct?

enter image description here

One can't simply apply DDD 'techniques'. DDD is about modelling the Domain correctly, not pressing buttons according to a recipe. Why the Order is an Aggregate Root? Which is the bounded context, is the OrderType an intrinsic feature of the Order? What does the Domain understand by OrderType? DDD really isn't about choosing/guessing entities and value objects. And when I see a one to many relatinship I'm 99.99% certain you're not doing DDD, you're still using the rdbms mindset, which has no place in DDD when modeling domain. — MikeSW, Apr 20 '14 at 12:32
@MikeSW:In summary: 1. Order is aggregate root, because it is responsible for persistence of Order and OrderLines 2. The bounded context is sale 3. Yeah OrderType is intrinsic feature of Order(some values for OrderType:InternalOrder,ExportOrder,...) 4. Why you say "when I see a one to many..."? Does, having a one to many relationship in model, have inconsistencies with DDD principales? — Masoud, Apr 20 '14 at 16:00
I'm afraid you got it all wrong, Aggregate Root has **nothing** to do with persistence, it has to do with domain concepts. I suggest you read more about DDD and just use 'normal' OOP until you understand it properly. At least you won't be under the (wrong) assumption that you're doing DDD. — MikeSW, Apr 20 '14 at 17:08
@MikeSW sounds like you got it wrong. Persistence is totally related to transaction in DDD. The purpose of the aggregate is to control the atomicy of the transaction mainly when executing DML. And how do you relate the objects if not based on relation ? The same relation you use in OOP HAS-A... how many of it... What are you talking about ? — mabreu0, Mar 15 '22 at 02:03
@mabreu0 An aggregate defines (indicates) a Unit of Work of domain data that needs to be modified at the same time. How you decide to implement it, that's an implementation detail. You don't relate objects, you reference domain concepts (entities) via their Id or the minimum relevant model for that use case. AR is a role that can be implemented as a function. There's no need for object to table approach unless you want that. DDD mindset != OOP/CRUD mindset . DDD uses models, not objects or tables. — MikeSW, Mar 17 '22 at 17:15
@MikeSW I see, then this questions pop up. What's the purpose to keep that unit of work together ? And how do you relate the objects in that Unit of work without some kind of identifier ? isn't the idea to persist that unit no matter what the store is ? — mabreu0, Mar 19 '22 at 15:09
@mabreu0 The idea is that the aggregate is just information about the data that needs to be changed at the same time. For example, I can represent that change as a domain event (1 data structure) persisting it in one 'Events' table as a source of truth and for querying purposes, update other tables, all in one db transaction (that is not the one defined by the aggregate). An important thing is the all DDD patterns organize relevant information according to different criteria, it's up to you how you translate that into code. — MikeSW, Mar 19 '22 at 15:31

score 1 · Answer 1 · answered Apr 20 '14 at 17:53

There is a common question "Entity vs Value Object".

what about OrderType? Is it also contained in Order aggregation or is it a Value object? I think it will be a value object. Am I correct?

I would say that OrderType is an entity but it depends an your domain.

The difference between Value Object and Entity is simple:

Value objects are considered the same when all their properties are equal.

When you care only about the attributes and logic of an element of the model, classify it as a value object. Make it express the meaning of the attributes it conveys and give it related functionality. Treat the value object as immutable.
Entities are considered the same when they have the same identity.

When an object is distinguished by its identity, rather than its attributes, make this primary to its definition in the model. Keep the class definition simple and focused on life cycle continuity and identity.

There is a simple “litmus test” for Entities:

If two instances of the same object have different attribute values, but same identity value, are they the same entity?

score 0 · Answer 2 · answered Apr 19 '14 at 14:29

As always "it depends..."

From your description it seems that it should be a Value object or, as Eric Evans means, Readonly entity without identity.

Should OrderType be a separate entity (can be sent to another objects) or it is small part of Order object?
Should OrderType has identity and be unique object even with same fields (Code, Title)?

Yes -> Entity with ID; No -> Value object

score 0 · Answer 3 · answered Apr 19 '14 at 16:58

0

It's possible you may not even need a class to model OrderType. An enum with an attribute may be sufficient if your programming language supports it, e.g.

public enum OrderType {
  [Code("ABC123")]
  OneTime = 0,
  [Code("XYZ456")]
  Repeating = 1
}

answered Apr 19 '14 at 16:58

Josh Kodroff

27,301
27
95
148

Value objects in DDD

3 Answers3