0
Modelling a project I associated an entity Addressee at the Root of Aggregation Client. So far so good. However, I later found that other entities or roots of aggregation such as Enterprise and Supplier They also need an address in their composition. Therefore, the question I have is how to use the same Address entity to serve all entities that need it? Obs: the modeling I’m doing is based on the concepts of DDD.
1
You have modeled the Address entity as Customer’s daughter entity, but it is only a related entity.
Normally, when I’m designing a concept, I feel the need to be skeptical about it, that is, to doubt what I know of it. So I usually end up discovering something new that changes the design.
That said, the best thing to do is to understand how Post office identify an address. What I reproduce below for historical purposes:
Item 1 we usually assign to another entity, such as, in your case, Customer, Company and Supplier. Item 6 is immutable because a different latitude and longitude represent a different address/location.
For items ranging from 2 to 5, all can be changed. Examples:
In either of the above two examples we, developers and users, want that once an attribute has been changed, the new value is applied to everyone using that attribute. That is, if a street has changed its name, the desirable is that the new name be applied to all customers and suppliers who reside there.
This shows us that an address has a life cycle and that if one of its attributes changes, it can still be the same address. Therefore, address is an entity, not an object of value.
Daughter entities are those whose life cycle is directly linked to that of the parent entity, such as a project and a task (task). A terefa exists only within a project and when a project is deleted, the task is also.
Related entities are those that are linked to other entities but have an independent life cycle, such as addresses.
Finally, an aggregate may contain parent entity, daughter entities and value objects. An aggregate shall not contain related entities.
Hello Tobias, actually I have in the database only a table called Address and in the application its modeling. I think I expressed myself badly when I said "...how to use the same entity Address to serve all entities". I would like to have a single table in the bank and store addresses coming from all possible places (however each address belonging to an owner that can be a company, a customer, a supplier, etc.)... my reasoning is adequate or has a more elegant way of normalizing this scenario?...
@Marceloalmeida is all right, what you commented now is the same that I had understood from your initial question. Your use case is what I described in the third paragraph of my answer. The database is right, what you need to change is the architecture of your code: put the Address entity at the same hierarchical level of Customer and access Address through the Customer Report (i.e. do not use your ORM to access Address directly from Customer, if your ORM is Active Record)
@Marceloalmeida edited the answer to make it clearer. See if you have any questions.
0
Yes, the address class will use the Valueobject convention in a directory within your domain. However, it would be correct for you to persist (database) in separate and related tables in your respective domains or even use the tables of the main aggregation entities. Valueobject is immutable, so for example, when adding a new address you should remove the current one and add the new one, for this it is "allowed" to create behaviors that help you in this scenario and the same ones can only be accessed from the root entity of the aggregation that uses it.
Knowledge material:
Browser other questions tagged classes ddd
You are not signed in. Login or sign up in order to post.
What language are you using? How is your code?
– Vinicius Fernandes