DDD领域驱动设计批评文集 《软件方法》强化自测题集 《软件方法》各章合集 第五元素202311621:29 潘老师,有个以前问过的问题,重新回顾后发现自己还是不太理解,请教一下: 案例一:答题抽奖,愿景描述的改进指标也是UMLChina训练中,花费在回答问题和抽奖上的平均时间,为什么叫UMLChina系统而不是UMLChina答题抽奖系统? 文中给出的解释是:注意,引进的系统依然叫UMLChina系统,并非UMLChina答题抽奖系统。答题抽奖可以看作由若干用例组成的用例集。我没太理解。 UMLChina系统似乎能表示的范围要更大,可能包括UMLChina办公自动化系统、UMLChina小金库管理系统等等,用UMLChina答题抽奖系统不是更直接、更加具体吗?不是要从目标涉众的角度去命名吗? UMLChina潘加宇 如果一个思考方式导致(1)都不用思考,一一对应就完了;或者(2)怎么思考都行,好像都是对的 那么这个思考方式肯定有问题。 如果按照你说的情况,那么可能会导致: (1)一个用例一个系统 或 (2)一个执行者一个系统,把自己相关的用例集看作系统 或 (3)不同的人看法不同,系统的答案也千变万化,把自己感兴趣的用例集看作系统。 如果是这样,系统这个词就不再有意义,不只是UMLChina系统这样的信息系统,所有提供一个以上用例的系统甚至物体都会面临这个问题。 但是,现实生活中并没有出现这样的混乱,我们在商店买个什么什么,说的还是一个一个的东西,概念还是比较清楚的。 这里面的关键点和定位老大、愿景、还有国安球迷在取款机上刻字一样的,就是一个最字。 回到UMLChina系统,这里面最重要的涉众就是潘加宇,这个最佳的答案是通过揣摩潘加宇的心意得到的。 谁来揣摩?研发人员(或者缩小范围,需求人员),这个人目前好像也是潘加宇。 嗯?潘加宇还要揣摩潘加宇的心意?当然,人要看清自己需要什么,也是很不容易的?那个什么明,郭敬明还是黄晓明不是有句名言嘛,破山中贼易,破心中贼难。 这两个链接也可以认真体会一下 是增加了一个功能还是增加了一个系统 屌丝可以接受土坑酸菜面吗架构可以影响需求吗 第五元素202311820:07 潘老师,我还要再问一下:我正在做某市的用于城乡规划会议的辅助系统,老大是该市的市长,改进的指标是提升该市规划项目审批的直观性和科学性该系统应该叫什么呢?某市系统?还是某市会议辅助系统? 或者直接一点说:凭什么认为潘加宇心里认为的就是UMLChina系统? UMLChina潘加宇 这个答案还是在前面我发的内容里面。 凭什么认为潘加宇心里认为的就是UMLChina系统?这个是揣摩出来的买卖之间的的一个最佳的平衡结果。至于潘加宇具体是怎么揣摩潘加宇得到UMLChina系统这个答案,中间的道理嘛涉及UMLChina组织的顶级商业机密 暂时还不能说。 同样的,生活中各种东西,凭什么这个东西是这个样子拿出来卖?都是揣摩过老大心意之后拿出来的(认为的)最佳结果。 市长这个,还真不知道,得揣摩市长的心理。 这里面要提醒的:把建模和交流分开。 从掌握了各种软件工程知识的人看来,这个东西应该叫A,但不妨碍和不同涉众交流时,把它叫B、叫C 这个可能才是你想要的答案 特别是,有可能市长以为他想要A,而通过严肃的推理,实际上他要的可能是B,他自己并不知道。 可以多捉摸书里或文章里反复提到的患者和医生的类比。 特别要警惕,屁股不要坐歪了。 虽然强调揣摩涉众,从涉众视角看问题,但思考的责任全在研发者这边,并不在涉众。 是你想要【做个什么东西来获利】,然后就带来了一系列的思考,例如,基于你的资源,判断解决哪个人群或机构的某些问题,你可能会有机会赚钱(老大和愿景);一旦下定决心杀进这个战场,你就要去如实调研目标人群或机构的现状,后面一系列你都知道了,最终在某个时间点拿出来一个东西,喏,就是这个。参考屌丝可以接受土坑酸菜面吗架构可以影响需求吗。 这些思考是你的责任,不是涉众的,其实涉众根本不在乎有没有你,或者有没有你的东西,毕竟这么多竞争者,多你一个不多。