10
I am studying on Ddds from the books of Eric Evans and Vernon. During reading I came across the implementation of Value Object, I even understood the concept but could not abstract to a real situation within a domain.
I joined the following tutorials and one of them more confused than helped:
The question is how to identify a value Object and when to use it?
8
In my opinion DDD tends to complicate what is simple. This discipline calls value Object what is usually called the types by value, and of entities what is usually called the types by reference. Understand more about this in question about C#.
Types by value have their own identity and any change in their value has another object, without altering the identity, while if two distinct objects have exactly the same state they can be considered equal. Types by value do not have associated objects, the object is treated directly in your storage location. They exist independent of other objects.
Types by value are usually immutable and small. They represent something unique, such as quantifications or very simple descriptions. Types do not escalares of any language are usually value Objects.
There are cases of types that are by reference as facilitator, but they remain value Objects, is the case of string.
Dates are usually great examples. Codes, various monetary values or other quantities, location points, identifiers, telephone, any simple descriptive data (URL for example), etc.
Sorry Maniero, but DDD is not a simple methodology, it is for complex software and with a lot of rules of business, to say that DDD complicates what is simple is a superficial opinion of a solution. Value Objects represent objects that have no identity, that is, their concept within the domain, however, it does not need to have its state persisted, it MAY be a type of value (struct) but it is not mandatory nor necessary in most cases. Let go of the obsession with primitive types. https://enterprisecraftsmanship.com/2015/03/07/functional-c-primitive-obsession/
Yes, the opinion is superficial, a complete does not fit in this question or even in the site as a whole, would need a book. For a more complete I am available for consulting. Everything to talk about the subject I already know, and generally in development as a whole, after all I do it in a very deep and studied way for 35 years. What you said is an idea that makes software as bad as it is today (what I have talks about) A lot of rules that don’t solve real problems and that cause others. But in fact there’s no room here for you to be shallow.
When you don’t use it the way I showed it, it gets worse. And these methodologies tend to have Abstraction Obsession which is an anti-pattern playing under the carpet because it does not meet the "Nterprise methodologies", but which is a real and measurable problem. That’s why I always say that people need to stop following good practices and learn the fundamentals and analyze the context to use things. People tend to complicate what is simple based on fashionable cake recipes.
I worked probably on the most complex Brazilian software ever written, with an unbelievable amount of business rules and didn’t even come close to needing DDD, in fact this would have caused damage. As I always say choose your poison. I prefer simplicity, some prefer to be fashionable. In general people cannot demonstrate real gains using more complex methodologies or following patterns without understanding their real motivation and functioning and all implications of their use.
This would be valid if in fact the software project was a simple task, and the traditional software methodologies were efficient. In fact, the DDD may seem more complicated at first, but as we study and understand the reasons for such a ban, things make sense, and the quality of our software improves. Things get more organized, and you can repurpose the code in the future. One thing is to optimize the code and decrease the number of lines (an old outdated approach). Another thing is to organize the software and the whole development process. Be Agile
@Ricardodarochavitor I "love" beliefs. The day someone presents proof that a project done by competent people is better in a general sense if using DDD, then I "believe". I ask this and people only say what they think. I can’t adopt a tool just because other people use it and say it’s good. I want to see all the data, I will equip if the evidence presented were in the same circumstances of the projects I do (which by the way is what almost everyone does), also I can not work with exceptions. Otherwise falls into "terraplanism".
1
So young, it’s not so complicated or mystical...
To help, the guy at Devmedia quotes Wikipedia... and still says nothing with nothing.. OK...
Think simply of the IMMUTABILITY of the object. The value object therefore DOES NOT CHANGE in the context of its application;
what about, if we think of a list of services, for example? services
see that the services that you provide to include in a tax note do not usually change, right? (hardly the government changes this type of list)
@Jcsaint, think of the software more lightly, and more fluidly. The software we write first serves us, programmers.
;-)
1
Very briefly it is the following:
See the following:
cliente: {
id: 1,
nome: "Thiago Lunardi",
sites: [
{ url: "http://thiagolunardi.net", tipo: "blog" },
{ url: "https://github.com/thiagolunardi", tipo: "github" },
]
}
Customer has identification, but Sites no longer have identification, are only values.
1
A value object works with aggregation. Two important rules: 1) They have no identity; 2) They are immutable;
What this means: If you have a customer and they only have a full address, and the address only exists as long as the customer exists... this is an aggregation, so it can be a value object. If you use a Relational Database, a value object is intrinsically within the parent entity, i.e., address (street, street, neighborhood, zip code, etc.) lives within the Customer Entity. However, if your business allows the customer to have more than one address, then we will no longer have domain exclusivity and it may not be a value object, but a class or entity participating in a relationship and with it will have an ID and not be immutable.
Browser other questions tagged pattern-design software-architecture ddd
You are not signed in. Login or sign up in order to post.
Really, these posts, for those who do not know much about DDD, play against it. But, it is very simple to use a Value Object
– Gabriel Simas