henlaotu
2013-07-03 17:34
虽然讨论的有点偏差,还是学到一些东西, 就是工作中要多思考少迷信。

另外,POJO还是Map都是技术实现的范畴内的吧,它们和分析设计领域好像没啥关系, 毕竟我们既不会和业务专家讲POJO也不会讲Map.

这段时间要做个项目,有许多问题向大家请教!

banq
2013-07-03 21:06
2013-07-03 17:34 "@henlaotu

"的内容

POJO还是Map都是技术实现的范畴内的吧,它们和分析设计领域好像没啥关系, 毕竟我们既不会和业务专家讲POJO也不会讲Map. ...

我们讨论没有偏题,只是楼主没有认识到问题严重性而已。

POJO不属于技术范畴,因为POJO也是一个Object,而Object在英语中不属于技术专业术语,日常用语经常涉及,如同我们汉语中“事物”一样。

我们的系统要实现业务专家的需求,也就是产品经理的要求,你要和产品经理交流,你不能和产品经理用技术术语,而你使用“订单” “发票” “商品”这些Object用语,产品经理肯定能懂,你们能用一种统一语言交流,否则你说这用一个MAP实现,产品经理一头雾水,而你说这用一个订单对象(POJO)表达,产品经理应该能明白。

软件是实现需求的,比如需求是电子商务系统,如果在你的软件中找不到订单这个POJO,而是置于MAP之下,这实际是技术绑架业务,那么需求和软件之间就存在一个鸿沟:

需求中订单 ---> MAP数据结构

而如下:

需求中订单 ---> 订单POJO

是不是很直接?软件代码和需求严格直观一对一,中间不需要任何翻译?

直接一对一的软件更易于维护拓展,不管哪个程序员维护拓展都比较轻松,这实际软件工程,而不是软件手工作坊。

px96004
2013-07-04 11:20
我感觉,要是都用MAP,程序员都蒙了。。。

windshome
2013-07-05 09:15
MAP也可以啊,但是MAP是实现层的事情,一定得有个“皮”,其实也就是封装的意思。

liyi237851708
2013-07-05 10:30
我也不懂领域模型,不过感觉光从技术层面说,用map也是一种悲剧啊,比如c#中存在的DataTable,从结构上来说感觉是个装载数据的好东西,但是从代码阅读上就很有问题

比如做开发时,经常要做接口,如果没有一份完整的API文档,肯定是场悲剧,假设我写了这样一个方法

public List<Map<String,Object>> getResult(Map<String,Object> map);

你能理解这样的参数,这样的返回值到底是要干什么么?

猜你喜欢