DDD领域驱动设计批评文集>>
《软件方法》强化自测题集>>
《软件方法》各章合集>>
第1章自测题 Part2
1. 开发人员说“根据客户的需求，我们的系统分为销售子系统、库存子系统、财务子系统……”，这句话反映了开发人员可能有什么样的认识错误？
A) 开发人员没有认识到面向对象设计的重要性
B) 开发人员直接从设计映射需求
C) 开发人员直接从需求映射设计
D) 开发人员没有用UML模型来描述子系统
答案和解析：
A) 错误选项。
B) 错误选项。即使对书中知识点不了解，从“根据需求”几个字也知道这个是错的。
C) 正确选项。
可能不少人觉得，这样说很正常啊！但实际上这是直接从需求映射到设计了，如下图。
图1 用例集和子系统
开发人员口中的“财务子系统”，说的很可能是财务人员所使用的“系统用例集”或者“需求包”，是从外部使用的视角来分割的。“子系统”应该根据内部各部件的耦合和内聚情况来划分，“外部划分”和“内部划分”不是一一对应的。
图1中，用例01用到组件01和04，用例02用到组件03、04、05，用例04用到组件03、05、07。组件是各个用例共用的，是系统的组件，不是某个用例专用的组件。
人也是一个智能系统。以人为例，图2中，一位男士有很多“用例”，有些是为老板提供的，有些是为老婆提供的，还有一些是为老爸老妈提供的，但不能说：人可以划分成“老板子系统”、“老婆子系统”……。
图2 男人作为一个系统的用例和组件
人确实可以划分成不同层次的“模块”（细胞→组织→器官→子系统），但这是根据内部各部件的耦合和内聚情况来划分的，和外面的划分没有直接的映射关系。
不能说心脏是老板的，双手是老婆的。其实，不管在公司996为老板服务，还是在家里为老婆服务，都需要强大的心脏和灵活的双手。模块是大家共享的。
微服务架构
最近几年鼓吹的新词“微服务”造成一定的误导。有的人误以为“微服务”就是“需求设计一一对应”。
例如图2中的男士，可能会被分割为“996微服务”、“交作业微服务”、“扛煤气罐微服务”。
且不说这样划分是否合理，即使这样划分了，“微服务”内部也要通过自己的各个部件（可能是残缺的）协作完成，例如“交作业微服务”要完成“交作业”用例，也需要眼睛、耳朵、手、脚、心脏、**等（可能是残缺的）协作完成，并非映射一个“交作业模块”然后就搞定。更何况，有的用例需要若干个“微服务”协作才能完成。
另外，“微服务”是妥协的不良结构。
“微服务”只是一种组件划分的风格，如果这样的划分风格所得到的软件结构真的是良好的结构，我们几十年前就可以这样做，不必等到今天才大兴“微服务”之风。
两座大楼耸立在那里，要判断地震来了哪座大楼不容易塌，要考虑的是大楼的结构、所用的材料、所在位置的地质环境等，和这座楼是哪家公司建造的，要了多少钱，建造大楼的公司是怎样的组织结构，甚至大楼是猫建造的、狗建造的、外星人建造的，已经没有直接关系，因为大楼已经耸立在那里了。
但研究这些直接的影响因素，涉及到艰深的工程力学、材料学和地质学知识，很多人是不会的，甚至有的人还懒得去学。
于是，有人就干脆这样做，有几个包工队跟自己混，就把一座大楼分几个包，这样大家都Happy，盖出来的大楼爱咋样咋样，勉强能住人就行。
这本来可以理解，讨生活嘛，不寒碜。所谓“康威定律”也只是说“are constrained to（被迫）”。
但如果理直气壮地吹嘘，这样盖出来的大楼“结构最精妙坚固”，这就是自欺欺人了。
关于这方面的更详细内容，可以关注《软件方法（下）》的后续发布。
[新增EA028高压注射器]24套UML EA和StarUML的建模示范视频-全程字幕（2022.7.4更新）
7月21-24晚剔除“伪创新”的领域驱动设计-网络公开课
7月28-31晚网课：软件需求设计方法学全程实例剖析
《软件方法》书中自测题-题目全文 分卷自测（1-8章）16套111题
《软件方法》强化自测题集110题
CTO也糊涂的常用术语：功能模块、业务架构、用户需求……[20210217更新]
如何选择UMLChina服务
