wy2023-02-20 来自广东来个彩虹屁吧，我感觉关于工时项的相关需求设计得挺好的，很符合目前需求迭代的节奏，而且需要一定的设计能力; 这部分工时项的需求，看起来很简单(pm角度)，但实际上如果没有良好的设计，我估计实现出来就是依托答辩，后续新增的需求只能是难上加难🤣作者回复: 这说明您确实有实际项目经验 🐮 共同提高！
1- wy2023-02-19 来自广东对于工时项map from项目有些疑惑，总感觉应该是反的，因为工时项应该算是抽象，为啥这里要感知具体的实现; 我理解应该是在项目管理上下文中有一个工时项实体(map from工时项管理上下文)，然后项目实体还是会有一条泛化的线指向这个工时项实体
作者回复: 这样就造成了项目管理对工时项的耦合。
共 3 条评论1 
阿甘2023-05-27 来自北京请教钟老师：拆分上下文过程中，项目、子项目到工时项的泛化关系为何要去除？保留这个泛化关系好像更容易说明其业务关系。（是为了最小化模型之间的依赖吗？）作者回复: 泛化会增加模型的复杂性，如果不是很必要，还是不用
BMX2023-03-27 来自上海“这也意味着，在代码的目录结构中，在根目录下面，首先为这 3 个上下文建立 3 个包，每个包内部，再按分层架构来进一步分包。”这里有个疑问：组件(界限上下文)之间如果有调用关系，如"projectmng"需要调用"basicinfomng"，那么调用的是API层，应用层还是领域或聚合层服务呢？作者回复: 下节课就讲到了
hacker time2023-03-06 来自湖北这是原文“在代码的目录结构中，在根目录下面，首先为这 3 个上下文建立 3 个包，每个包内部，再按分层架构来进一步分包”，不理解这句话，是不是在IDEA开发工具里面首先新建一个maven project，然后在src新建3个并列的上下文的包，然后在每个包里新建adapt er,application,domain的包，在adapter目录下新建drive和driving包？这样和迭代一的代码目录结构很不一样了作者回复: 是
赵晏龙2023-03-01 来自湖南1、我没有太明白，这个map from 到底是指在子模块中自我维护一个状态，还是从外部接口获取？如项目成员->工时项成员，【工时项成员】是否需要在【工时项系统】中做冗余？这决定了这道题的答案。按照我的理解，如果需要一条SQL查，隐式的说明这是一个数据库内，也就是一个子系统内。一个join应该就能查出来。作者回复: 就目前这个场景，【工时项成员】在【工时项系统】中做冗余比较好些。这是因为，【工时项成员】中的内容，可能不止来源于【项目成员】，还可能有非项目的工时项，也要安排成员。
铿然2023-06-20 来自江苏有点复杂，先把业务需求和场景说清楚再展开设计更容易理解，否则要么不理解，要么会觉得是过度设计。
aoe2023-02-28 来自浙江工时管理依赖的上下文真多啊，有：基础信息管理、项目管理、假期管理