Search code examples
phplaraveldomain-driven-designvalue-objectshexagonal-architecture

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


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
);

Solution

  • 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.