说实话对于主要是应用层面的开发的我来说，这一节不是那么容易理解。
领域语言，按照我们DDD的想法，想当然的认为他是描述某个业务范畴的语言，比如说在运输领域，比如说在计费领域，比较遗憾的是在这些业务领域并没有我所知晓的领域语言，也就没法实现所谓的产品经理直接编程的看上去很美的目标。
咨询了我们开发的老大克斯，给我的讲解是这个领域语言并不是业务领域，而是某些更通用一点的技术领域。好吧，领域这个词听上去挺高级的，业务可以有领域，技术也可以有领域。比如在配置领域，或者在测试领域。
实际上书中称为领域语言，我感觉更可以把范畴扩大一点，变成一种领域产品。比如在配置领域有个XXX产品，帮我们封装好了xxx的方法，从此以后产品配置变得简单。在测试领域有个xxx产品，帮我们做好了基础服务，编写测试用例非常简单，BA可以自己写测试。当然everything is OK。
有成熟的，现有的，免费的或者是少量收费的产品或者叫领域语言来帮我们减轻工作量当然是欢迎的，但是实际上除了本身的费用外，他也产生了一些额外的成本，比如把代码架构变复杂了一丢丢，有的时候依赖其中的实现可能欠缺一点灵活性，或者有一点潜在bug的风险，当然大部分时候是物有所值的。
最后是作者给的原则，一，能用尽可能用；二，用的时候考虑一下收获和代价。当然这是总是正确的废话。
以上浅见受制于本人能力问题不一定准确，权且看看，有更好的见解欢迎交流。
网友评论