After many searches on the internet, I came across many divergent opinions ...
In my application, I created enum EstadoCivil {Casado = 1, Solteiro = 2, Divorciado = 3} . Can it be classified as an Object Value, or is it simply an enumerator that will relate to my class?
Why Object Value is meaning Value Object? If this is an enumeration it is a Value Object (it has everything it needs to have to receive this rating), then there is no dichotomy.
If someone thinks that an enumeration is not a Value Object that says why. I did not see anything that indicates that she is not.
Many people will find it wrong to use enum because this is a mechanism for dealing with internal mechanisms of the code and not to deal with business rule abstractions. But there are controversies, so think divergent opinions.
Can the range of possible values change? It seems to me that it can, even if rarely. If you change, do you want to work with an extension of this or remodel the application? It has arguments for both. Some people adopt by default to be able to extend the application without touching anything else. It looks good, but in practice in various scenarios there are problems doing so.
In fact there is Microsoft's own recommendation to use a normal class instead of an enumeration in certain (not all) scenarios.
Making a class tends to complicate the application. But there are cases that are necessary or useful to solve other issues.
If you do DDD without knowing why you are doing it, getting complicated (and DDD tends to complicate the application) without having a clear gain (and a lot of what people do does not have a clear gain) is doing wrong there, no matter what be. If you're doing something you do not fully understand (people often use things they think they understand but do not understand) then it's the wrong tool.
For me it's not a question of being DDD or not, it's a matter of necessity.
Additionally I say that in some scenarios there is standardization of this information .
