value-objects

I don't get why value objects in DDD should be immutable, nor do I see how this is easily done. (I'm focusing on C# and Entity Framework, if that matters.) For example, let's consider the classic Address value object. If you needed to change "123 Main St" to "123 Main Street ", why should I need to construct a whole new object instead of saying myCustomer.Address.AddressLine1 = "123 Main Street"? (Even if Entity Framework supported structs, this would still be a problem, wouldn't it?) I understand (I think) the idea that value objects don't have an identity and are part of a domain object, but

I'm trying to design a pretty simple app and am getting myself a bit confused with Hibernate's definition of entity and value objects (as defined in Chapter 4 of Java Persistence with Hibernate). What I have is an app with customers, who can place orders (one to many relationship). Each of these orders has many order lines (also one to many). Now, I think that customers have identity (customer number) and so do orders (order numbers) so they are therefore entity objects? My confusion comes in with the order lines. An order line has quantity, product number and price. An order line can't exist

Value objects do not have identity. ORM needs identity to update the database. How to trick ORM? (Marking Id for value object as internal won't work because ORM lives in a different assembly and moving it to the same assembly is not acceptable). Thanks in advance. As far as my understanding of DDD goes value objects are just a way to partition your entities. If a value object should be stored with an ID in the database it's not a value object. Example: The domain model looks like this (C#): public class Customer : Entity { public Guid CustomerID { get; } public string LastName { get; set; }

#1. Validate EmailAddress on the Form I have a backend form class with an emailAddress property that has validation logic so that I can return an error message back to the user. I validate all form inputs with something like: $form->fillWith($request->input()); if($form->validate()){ $form->dispatch($command); // if synchronous, form takes command's messageBag } return response($form->getMessageBag()->toJson()); #2. Validate EmailAddress Value Object in the Command Handler I have a command handler that will take the primitive string email and create a value object. The value object will throw

(This question uses PHP as context but isn't restricted to PHP only. e.g. Any language with built in hash is also relevant) Let's look at this example (PHP): function makeAFredUsingAssoc() { return array( 'id'=>1337, 'height'=>137, 'name'=>"Green Fred"); } Versus: class Fred { public $id; public $height; public $name; public function __construct($id, $height, $name) { $this->id = $id; $this->height = $height; $this->name = $name; } } function makeAFredUsingValueObject() { return new Fred(1337, 137, "Green Fred"); } Method #1 is of course terser, however it may easily lead to error such as

I have just started reading DDD. I am unable to completely grasp the concept of Entity vs Value objects.. Can someone please explain the problems (maintainability, performance.. etc) a system could face when a Value object is designed as a Entity object? Example would be great... Reduced to the essential distinction, identity matters for entities, but does not matter for value objects. For example, someone's Name is a value object. A Customer entity might be composed of a customer Name (value object), List<Order> OrderHistory (List of entities), and perhaps a default Address (typically a value