软件方法（下）分析和设计第8章分析 之 分析类图——知识篇（20211227更新）
软件方法（下）分析和设计第9章分析 之 分析类图——案例篇（20211228更新）
问题时间：2012/10/25
593 (585**01) 2012-10-25 13:24:05
恼人的CRUD，可是我的项目就是维护一个数据库呀 潘加宇(3504847) 10:05:07 什么叫"维护一个数据库"，做什么系统背后不都是维护数据库，玩游戏也是"维护一些数据"。背后还是一台台计算机呢。 如果你在这个项目的角色是DBA，另有人做需求，那需求就不管你的事 如果你负责做需求，就要想清楚这个项目要卖的是什么 593(585**01) 10:15:36 系统就是维护CMDB 593(585**01) 10:15:58 通过系统来维护，不是通过sql来维护，这个我还是分得清的 593(585**01) 10:16:42 比如说做一个phpmyadmin 潘加宇(3504847) 10:40:34 既然如此，直接用phpmyadmin不行吗？别的数据库也一样有类似的管理工具。 “通过系统来维护，不是通过sql来维护”，什么叫通过系统来维护？ --------------- 其实很可能是这样的，你做的其实是一个CMDB的工具。 可能的需求是：“同步配置信息” 至于是通过图形界面做到，通过一句命令来做到，还是管理员嘴巴里念一句咒语做到，这个需求实现起来用了多少行代码，用到数据库中多少个表，写了多少句SQL语句，还是不直接使用SQL语句，是无所谓的 --------------------- 需求和设计往往是多对多的，如果从里到外都是一对一的，这层层包装有何意义， 593(585**01) 10:49:00 一下说到点子上了。我提取出来的需求：维护配置信息。可能还是"同步配置信息"比较形象点。 593(585**01) 10:50:59 实际上，我想说的是用例的粒度问题。同步配置信息的操作会有新建配置信息、修改配置信息、删除配置信息。放到一个用例里描述，内容太多了。参考了一些文档，说是可以单独提取出来。一直在纠结要不要提取出来 潘加宇(3504847) 10:53:08 说这些没有意义，你要去研究负责维护CMDB那些人的工作，从业务序列图中映射合适的用例
DDD浮夸，Eric Evans开了个坏头
我为什么写《DDD浮夸，Eric Evans开了个坏头》
[全文]DDD话语批评之一：评张逸的“状态和事件本质相同”
