Kwa*_*adz 3 java oop domain-driven-design naming-conventions
现在托管在Github存储库中的DDDSample项目似乎是关于如何设计DDD项目的参考.
我注意到域类中的所有getter都不以get(ex :)为前缀,Cargo#delivery而它们在域包之外的类中加前缀(例如:) HandlingEventRegistrationAttempt#getTrackingId.
理查德·C·马丁在他的"清洁法典"一书中说:
应根据javabean标准为访问器,变换器和谓词命名其值,并以get,set为前缀.
那么,我们应该避免在这种背景下遵循他的建议吗？如果是这样,为什么它比一致性更重要？
为什么来自域类的getter不应该在DDD中以"get"为前缀？
起点容易的地方是变异者 ; 请注意清洁代码中的前一句
Mutators应该有动词或动词短语名称,如postPayment,deletePage或save.
这个想法与域模型不应该是贫血的原则是一致的,并且域的语言应该是无处不在的:我们应该在我们的域专家在解释业务时使用的代码中看到相同的语言.
这就是为什么你不会set经常看到的原因,除非这个动词碰巧在你的领域中具有重要意义.
访问器和谓词都是查询的示例.正如Bertrand Meyer所理解的,查询在不修改实例的情况下提供有关实例的信息,并且它们满足统一访问原则
从外部来看,查询是属性(每个对象中的字段)还是函数(算法)不应该有任何区别.例如,a_vehicle.speed可以是一个属性,可以从对象的表示中访问; 或者它可以通过一个按时间划分距离的函数来计算.两种情况下的表示法都是相同的,因此在不影响软件其余部分的情况下更改表示很容易.
那么,这些应该如何命名呢？
Vaughn Vernon在实现域驱动设计中写道
无副作用函数的方法名称很重要.虽然这些方法都返回值(因为它们是CQS查询方法),但它们故意避免使用get-prefix JavaBean命名约定.这种简单但有效的对象设计方法使Value Object忠实于无所不在的语言.getValuePercentage()的使用是一种技术计算机语句,但valuePercentage()是一种流畅的人类可读语言表达.
史蒂文罗威写道
开发人员倾向于用开发术语思考和交谈,这自然会导致无意识的模型,而不是什么和为什么.这很常见,而且它是一个焦油坑,因为开发人员倾向于遵循既定的模式.更重要的是,一旦代码的真正目的变得模糊,任何人都不可能发现它.
我会用这种方式表达这个想法:域专家应该能够读取域模型中的代码,并评估其正确性.这意味着域代码不应该在其中嵌入与基础架构相关的工件.
罗伯特马丁这个想法的拼写？
读者不应该在心理上将你的名字翻译成他们所知道的其他名字.
(Martin后来断言,应该从解决方案领域中获取术语,前提是大多数读者都是程序员,而不是领域专家.DDD反驳的论点是,程序员应该在他们为业务建模时获得领域专业知识. )