软件方法(下)分析和设计第8章连载[20210816更新]分析 之 分析类图——知识篇
评张逸的“状态和事件本质相同”(上)-DDD话语批评之一
某知乎网友
如何零基础学会看UML类图?
UMLChina潘加宇
不了解零基础是怎么零基础法。
如果说指已经掌握某一门面向对象编程语言,只是没有接触过UML或类似图形表示法,那可以找一本有图和代码对照的书看看。
符合有图和代码对照着看的书,一种就是以你熟悉的编程语言写的GoF设计模式书,基本每门语言都有。
例如,你常用C#,就搜“C# 设计模式”或“C# Design Patterns”的书,常用Swift,把关键词里的C#换成Swift.....
然后挑一本书里面UML类图的量比较大的。
例如:
以下为凑字数文字:
8.2.4.3不要把“上下文”当作偷懒的遮羞布
“领域驱动设计”乱象中,和本节内容相关的一个现象是:把“限界上下文”当作遮羞布,闭门造车炮制“通用语言”。
例如,针对下面这段描述:
同样规格的联想ThinkPad X1 Carbon2021笔记本电脑,在淘宝的A店铺卖9999元,B店铺卖9888元,某单位从B店铺买了20台,贴上单位的条码编号,分配给员工使用。
有的人“哇,我发现(没错,他们不喜欢研读,喜欢'发现')商品在不同的上下文有不同的含义!”,活生生地把领域建模搞成玄学。
其实,好好思考一下,或者看看前人的归纳,就知道这里面涉及到不同的概念,在模型中如实描述即可,如图8-37,不需要故弄玄虚。
图8-37 如实描述领域概念
在不同上下文中使用同一称呼,而且有不同含义,这种情况当然是存在的,但应该在调查和思考之后确认。要提防因为没有能力或者懒得去剖析背后的区别,就随便乱说——我的上下文中,鹿就是马的意思,马就是鹿的意思,我的上下文里的商品和你的上下文里的商品不同……
8.2.4.4 核心域透镜
在为了软件开发而建模时,建模人员可能会用自己熟悉的非核心域术语体系来代替不那么熟悉的核心域术语体系,还引以为豪。例如,面对一段集装箱领域装箱规则的描述,建模人员立即在大脑中把它转换成自己熟悉的概念:栈、链表、树……而且认为这是“透过现象看本质”,甚至宣称“我就是程序,程序就是我”!
Fred Brooks在《人月神话》中引用了James Coggins的一段话: