The DDDSample project, now hosted in a Github repository, seems to be a reference about how to design a DDD project.
I noticed all the getters in the domain classes are not prefixed by get
(ex: Cargo#delivery
) while they are prefixed in the classes outside of the domain package (ex: HandlingEventRegistrationAttempt#getTrackingId
).
Richard C. Martin, in his book Clean Code, sates:
Accessors, mutators, and predicates should be named for their value and prefixed with get, set, and is according to the javabean standard.
So, should we avoid to follow his advice in this context? If so, why would it be more important than consistency?
Why getters from domain classes should not be prefixed with “get” in DDD?
The easy place to start from is mutators; note the immediately previous sentence in Clean Code
Mutators should have verbs or verb phrase names like postPayment, deletePage, or save.
This idea is consistent with the principle that the domain model should not be anemic, and that the language of the domain should be ubiquitous: we should be seeing the same language in the code that our domain experts use when explaining the business.
That's why you aren't going to see set
very often, unless that verb happens to have significance in your domain.
Accessors and predicates are both examples of queries. As understood by Bertrand Meyer, queries give information about an instance without modifying the instance, and they satisfy the uniform access principle
from the outside, whether a query is an attribute (field in each object) or a function (algorithm) should not make any difference. For example a_vehicle.speed could be an attribute, accessed from the object's representation; or it could be computed by a function that divides distance by time. The notation is the same in both cases, so that it's easy to change representation without affecting the rest of the software.
So, how should these be named?
Vaughn Vernon, in Implementing Domain-Driven Design, writes
The method names of Side-Effect-Free Functions are important. Although these methods all return Values (because they are CQS query methods) they purposely avoid the use of the get-prefix JavaBean naming convention. This simple but effective approach to object design keeps the Value Object faithful to the Ubiquitous Language. The use of getValuePercentage() is a technical computer statement, but valuePercentage() is a fluent human-readable language expression.
Steven Lowe writes
Developers tend to think and talk in development terms, which naturally results in inadvertent models of how instead of what and why. This is common, and it's a tar pit, because developers tend to follow established patterns. What's more, once the true purpose of the code is obscured, it's unlikely that anyone will unearth it.
I would express the idea this way: domain experts should be able to read the code in the domain model, and evaluate its correctness. That means that the domain code should not have embedded within it artifacts related to infrastructure.
Robert Martin's spelling of this idea?
Reader's shouldn't have to mentally translate your names into other names they know.
(Martin later asserts that terms should be taken from the solution domain, from the premise that most of the readers will be programmers, rather than domain experts. The DDD counter argument would be that programmers should be acquiring domain expertise as they model the business.)
Unfortunately, the hardest thing in computer science, naming things, is also one if the most important one. A reader/client of your code should understand what the method do just by looking at its signature. If he needs to read the method's body too in order to understand what it does then you've failed.
So, if somehow, by some team rules, or something else, you can understand that a particular method is a getter without using the "get" prefix then don't use it, otherwise use it because we, the other ones, expect to see a "get" in front of a getter.
P.S. this is orthogonal to DDD.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With