java - Should getters from domain classes not be prefixed with "get" in DDD, and why? -

the dddsample project, hosted in github repository, seems reference how design ddd project.

i noticed getters in domain classes not prefixed get (ex: cargo#delivery) while prefixed in classes outside of domain package (ex: handlingeventregistrationattempt#gettrackingid).

richard c. martin, in book clean code, sates:

accessors, mutators, , predicates should named value , prefixed get, set, , according javabean standard.

so, should avoid follow advice in context? if so, why more important consistency?

why getters domain classes should not prefixed “get” in ddd?

the easy place start mutators; note previous sentence in clean code

mutators should have verbs or verb phrase names postpayment, deletepage, or save.

this idea consistent principle domain model should not anemic, , language of domain should ubiquitous: should seeing same language in code our domain experts use when explaining business.

that's why aren't going see set often, unless verb happens have significance in domain.

accessors , predicates both examples of queries. understood bertrand meyer, queries give information instance without modifying instance, , satisfy uniform access principle

from outside, whether query attribute (field in each object) or function (algorithm) should not make difference. example a_vehicle.speed attribute, accessed object's representation; or computed function divides distance time. notation same in both cases, it's easy change representation without affecting rest of software.

so, how should these named?

vaughn vernon, in implementing domain-driven design, writes

the method names of side-effect-free functions important. although these methods return values (because cqs query methods) purposely avoid use of get-prefix javabean naming convention. simple effective approach object design keeps value object faithful ubiquitous language. use of getvaluepercentage() technical computer statement, valuepercentage() fluent human-readable language expression.

steven lowe writes

developers tend think , talk in development terms, naturally results in inadvertent models of how instead of , why. common, , it's tar pit, because developers tend follow established patterns. what's more, once true purpose of code obscured, it's unlikely unearth it.

i express idea way: domain experts should able read code in domain model, , evaluate correctness. means domain code should not have embedded within artifacts related infrastructure.

robert martin's spelling of idea?

reader's shouldn't have mentally translate names other names know.

(martin later asserts terms should taken solution domain, premise of readers programmers, rather domain experts. ddd counter argument programmers should acquiring domain expertise model business.)