DDD, problem with value objects and "new Domain()"-CodePudding

I have a question,

I am migrating from MVC to hexagonal architecture and DDD architecture in a laravel project.

I understand that a value object represents an attribute of table X but I have a problem, I have a table with 60 columns, would it have 60 value objects? That same table in the laravel controller has a join with 20 separate tables, the columns of those 20 tables are also value objects?

and a question, for example I ask for a records of the same table by the id, when I get the result and I must create the model, should I instantiate the 60 value objects?

example

$users = $this->user->find($id);

$user = new User(
    new UserId($users->id),
    value object 2,
    value object 3.... to 60 value objects
);

CodePudding user response：

I think the Value Object does not represent a Value, a Value object is the same as your model or entity but there are differences there.

Here is a bigger article found on stack overflow

https://enterprisecraftsmanship.com/posts/entity-vs-value-object-the-ultimate-list-of-differences/

There is an entire discussion about the differences between ValueObjects and Models

Value vs Entity objects (Domain Driven Design)

but a Value Object does not represent just the ID

CodePudding user response：

I would say that the whole joined table is usually a value object. Value object would be for example an address that contains street/town/country, etc.

Of course you can always describe every single column as a separate class, but in my opinion it's an over-engineering and if you don't expect any special domain behaviour for that value (method in value object class) it's a waste of time.

You should also consider if those 20 tables have to be a part of your entity. I usually use a relations within one entity table some tables related to this specific entity and I do not share these related tables with other entities. I don't create references between different enitities' contexts. Maybe you have a set of enitiest and you need a set of repositories/factories for them. And if there are two repositories you shouldn't join them at SQL level.

I know that every case is different, but you should always try to write small pieces of code. Small classes, entities, bounded contexts, modules, services, ... It's usually easier to deal with.