Exchanging Value Object in the database

Asked

Viewed 164 times

0

I’m reading the DDD (Eric Evans) book that says the implementations of Value Object are immutable and if you want to change it, you will have to create another one. In more common examples where there is a class Pessoa and another class Endereco, you recreate the address instead of changing the object, it works ok.

And I also read https://cargotracker.java.net/ and https://gojko.net/2009/09/30/ddd-and-relational-databases-the-value-object-dilemma/. But I have something a little different.

I am working on a Billing system, and contains 4 tables

Pessoa - campos: idPessoa, Nome -> <<Entity>>
Celular - campos: idCelular, Numero -> <<Entity>>
Vigencia - campos: idVigencia, idPessoa, idCelular, dataInicio, dataFim -> <<Value Object ou Entity????>> 

The Person table would be the employee register of the company, let’s suppose it has around 10 thousand records The Cellular table is data of all cell phones that the company has, let’s say some 3 thousand records

The table Vigencia is the associative Person X Cellular, example, the "Joao" is with the cell phone "11 91234-5678" in the initial date "01-01-2016" and the final date would be null meaning that still this cell phone is with him, and this record would have a "idVigencia" 1, which is not related to the business.

Now that we are on 20/08/2016, we know that "John" no longer owns this phone, and now is Maria. Then in the table "Vigencia" would update the "end date" of the vigencia of "João" to "31-07-2016" and create another record for "Maria" with the "start date" in "01-08-2016", so says the phone "changed" owner

Ligacao - campos: idLigacao, idVigencia, etc... -> <<Value Object>>

In the table of calls, we have calls the month 05, 06, 07 e 08 de 2016, where this phone is with João, then the FK of the idVigencia field of the Link table will be the number 1 in this case, only with the change of "Vigencia" of "João" the month 08/2016 would be with the wrong FK and should be reprocessed.

So "Vigencia" would be a Value Object ? (which is also my doubt, as it could perhaps be an Entity, but I don’t see an identity in the "idVigencia", perhaps in the set of fields)

If it is a <> the vigencia would be immutable and when updating the "João" placing the "final date" for "31-07-2016", would have to discard the object and create it again, only that enters the problem in relation to FK "idVigencia" of the table of "Link"

What’s the best way to implement this with DDD?

  • There is a relationship between idPeriodo and idVingencia, that’s it?

  • It is worth remembering that the approach, or even the architecture itself, should serve the need of your project, and not the other way around. Do you have a "restaurant napkin" flowchart? Start simple, make the tools work for you ;-)

  • @Marcoaurelio Thank you for the answer. I believe that the question lacked data. I will put in an answer below to be clearer information, all help is welcome, I took this problem as an example

  • As mentioned, a Value Object does not change. And, contrary to what is also mentioned in the question, there is no way to "change it". If, in any scenario, some value should change, and such a change is natural, then this indicates that it is not a Value Object.

2 answers

0

DDD is for the domain, tables is for persistence

Your rich OO model probably has the class Person, Duration and Telephone. I believe that in Duration there is a reference to Person and another to Telephone, in addition to other attributes. When it comes to a Value Object attributes cannot be changed (as this is in the nature of a Value Object), which is not the case with Duration. So, Duration is not a Value Object, as you can extend the final date, which is natural for a term, but does not make sense in a Value Object.

When one thinks of a Value Object V with the attribute x with a given value, if there is a possibility of x owning or assuming another value than that of V, then it is another object, it is not the same.

Finally, DDD aims to reflect faithfully on a domain, while tables focus on persistence, which are distinct and often conflicting topics. Persisting a rich OO model, in general using the relational model, introduces several challenges. The incompatibility between these models is known for impedance Ismatch (https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch). If you avoid the challenges, you are probably giving up the OO model, because your relational database will not fail to be relational.

0

It’s a typical problem to create Value Object structured in relational bases. Start to create ID for VO, by necessity, even knowing that a VO does not have ID by definition.

To really help solve your problem, I would need to know more about the business. But the little you’ve gone through, I’ll risk the following:

  • If the idPeriodo - that I imagine is the FK for Vigência, your problem is solved

And, to relate the links to the duration, you can only use the dates. Thus you are free to maintain the dates or any other Term property, without having to recreate all links.

To search for links in one term, you can use the idCelular more of the dates. I believe it will be performatic enough.

  • I changed the question by putting more details on the business, the date of the connection I believe that with the extremely high volume, can have an impact on performance :( . I hope I have managed to improve my above question that I edited

Browser other questions tagged

You are not signed in. Login or sign up in order to post.