Timeline for Do immutable objects and DDD go together?
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 28, 2016 at 7:06 | comment | added | andho |
@SteveEvers Talking about Immutable Value Objects here, namely the Address object. Customer, which is an Entity, is mutable. If you want to change the City in the address, you create a new Address and assign it to Customer instead of mutating it by calling address.setCity(...).
|
|
| Apr 27, 2016 at 22:39 | comment | added | Steven Evers | Customer is mutated by setting customer.address = new Address(...) | |
| Feb 21, 2013 at 9:43 | comment | added | andho | Yes that is one way to evaluate if an object is an Entity or Value Object. If you want to discuss and get help with these kinds of issues, the DDD/CQRS group is the place to go. It's very active and helpful with some industry experts pitching in. | |
| Feb 21, 2013 at 8:33 | comment | added | Sudarshan | @andho currency would still be owned by a particular entity for example product has a price (Currency). I am trying to find characteristics which would tell me that a concept should be modeled as Value Object. For example my current understanding is as follows. If in our domain a car engine can be swapped out and put in another car then it has existence of its own (Aggregation) and hence cannot be a Value Object ... However in our domain if the engine cannot be swapped out and hence makes no sense without a car then it can be modeled as a Value Object (Composition). Does this make any sense ? | |
| Feb 20, 2013 at 8:13 | history | edited | andho | CC BY-SA 3.0 |
Corrected a spelling mistake
|
| Feb 20, 2013 at 8:07 | comment | added | andho | @Sudarshan there are things like Currency that could be owned by different Entities and also could be just used for calculations in a Service. | |
| Feb 20, 2013 at 6:58 | comment | added | Sudarshan | Could we say that Value Objects would invariably be wholly owned composition (UML) by the parent ? Additionally a Value Object would make no sense without its Parent and cannot be shared between Parents ? | |
| Oct 25, 2012 at 13:23 | comment | added | Sudarshan | @andho " this is just a way to make an 'immutable value object', not really immutable in the database." this really made my day thanks | |
| Oct 25, 2012 at 10:15 | comment | added | andho | @Sudarshan to answer your question specifically, You just run an update query which updates the row to the new value. If it is one-to-many, then the addresses will have some kind of identifier within the Customer Aggregate Root which will be used to uniquely identify it in the DB. Then this identifier and customer_id will be used to update that row in the 'address' table. | |
| Oct 25, 2012 at 10:12 | comment | added | andho | @Sudarshan this is just a way to make an 'immutable value object', not really immutable in the database. For performance reasons. Each situation needs to be handled specifically ofcourse. I prefer Event Sourcing for my Domain now, but I am kind of addicted to it. | |
| Oct 17, 2012 at 16:50 | comment | added | Sudarshan | In the above case if we ever needed to change the city attribute of the address class for a given customer how would we handle it ?, Further assume customer could have multiple addresses so it a a one to many relation ship between customer and addresses | |
| Jun 6, 2012 at 13:58 | comment | added | Andres F. | +1 I agree with you on the general principle: I don't see why immutable domain objects must necessarily mean immutable DB rows. | |
| Jul 17, 2011 at 16:03 | history | answered | andho | CC BY-SA 3.0 |