29｜限界上下文（中）：限界上下文怎样影响架构设计？
钟敬
你好，我是钟敬。
上节课我们学习了“限界上下文”和“上下文映射”两个模式。
今天我们继续完成“工时管理”上下文，帮你进一步深化这两个概念。然后，我们会根据限界上下文来完成架构设计。由于这个迭代出现了多个上下文，所以架构设计的时候，我们首先要讨论的就是使用单体还是微服务。
为“工时项管理”上下文建模
沿用上节课的假设，你是开发组长，我是技术骨干，比你先学了一些 DDD，我们都是这个项目的第一批成员，共同承担着架构师的职责。
在为“工时管理”上下文建模之前，我们先回顾一下之前的模型。
你思考了一下，问：“工时管理和其他上下文的有一个区别，就是这里多了泛化。那么拆成上下文以后，是不是还要原样保持这个泛化呢？另外，考虑到请假信息也要报工时这个新需求，是不是说请假记录也要作为工时项的子类呢？”
我说：“让我先试着画一画，再讨论吧。”于是我为工时项管理上下文画出了后面的模型图。
看到这张图，你有些疑惑地问：“泛化跑哪儿去了？”接下来，让我们一步一步看一下。
“员工”的上下文映射
先看个简单的，和“项目管理”上下文一样，员工也是从“基础信息管理”上下文映射过来的。
“工时项”实体
下面看比较重要的工时项实体。
请注意，由于现在我们是专门考虑“工时管理”上下文，所以我们不必过多地受到“项目管理”和“假期管理”中概念的“拖累”，而是聚焦在什么样的模型对实现工时管理功能最有利就可以了。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文主要讨论了限界上下文对架构设计的影响，并围绕“工时管理”上下文的建模展开。作者首先介绍了工时项实体和其上下文映射，强调了限界上下文内部概念一致性的重要性。接着，文章展示了限界上下文的概念映射图，用UML依赖表示各个上下文的映射关系。最后，文章探讨了限界上下文驱动的架构设计，提出了单体和微服务架构的综合考虑因素。总体而言，本文深入浅出地介绍了业务概念和架构设计问题，同时提供了UML组件图的示例和架构设计的综合考虑因素。文章内容丰富，适合技术人员阅读。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《手把手教你落地 DDD》，新⼈⾸单¥59
《手把手教你落地 DDD》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(8)
- 最新
- 精选
wy来个彩虹屁吧，我感觉关于工时项的相关需求设计得挺好的，很符合目前需求迭代的节奏，而且需要一定的设计能力; 这部分工时项的需求，看起来很简单(pm角度)，但实际上如果没有良好的设计，我估计实现出来就是依托答辩，后续新增的需求只能是难上加难🤣作者回复: 这说明您确实有实际项目经验 🐮 共同提高！
2023-02-20归属地：广东2- wy对于工时项map from项目有些疑惑，总感觉应该是反的，因为工时项应该算是抽象，为啥这里要感知具体的实现; 我理解应该是在项目管理上下文中有一个工时项实体(map from工时项管理上下文)，然后项目实体还是会有一条泛化的线指向这个工时项实体
作者回复: 这样就造成了项目管理对工时项的耦合。
2023-02-19归属地：广东31 
阿甘请教钟老师：拆分上下文过程中，项目、子项目到工时项的泛化关系为何要去除？保留这个泛化关系好像更容易说明其业务关系。（是为了最小化模型之间的依赖吗？）作者回复: 泛化会增加模型的复杂性，如果不是很必要，还是不用
2023-05-27归属地：北京
BMX“这也意味着，在代码的目录结构中，在根目录下面，首先为这 3 个上下文建立 3 个包，每个包内部，再按分层架构来进一步分包。”这里有个疑问：组件(界限上下文)之间如果有调用关系，如"projectmng"需要调用"basicinfomng"，那么调用的是API层，应用层还是领域或聚合层服务呢？作者回复: 下节课就讲到了
2023-03-27归属地：上海
hacker time这是原文“在代码的目录结构中，在根目录下面，首先为这 3 个上下文建立 3 个包，每个包内部，再按分层架构来进一步分包”，不理解这句话，是不是在IDEA开发工具里面首先新建一个maven project，然后在src新建3个并列的上下文的包，然后在每个包里新建adapt er,application,domain的包，在adapter目录下新建drive和driving包？这样和迭代一的代码目录结构很不一样了作者回复: 是
2023-03-06归属地：湖北
赵晏龙1、我没有太明白，这个map from 到底是指在子模块中自我维护一个状态，还是从外部接口获取？如项目成员->工时项成员，【工时项成员】是否需要在【工时项系统】中做冗余？这决定了这道题的答案。按照我的理解，如果需要一条SQL查，隐式的说明这是一个数据库内，也就是一个子系统内。一个join应该就能查出来。作者回复: 就目前这个场景，【工时项成员】在【工时项系统】中做冗余比较好些。这是因为，【工时项成员】中的内容，可能不止来源于【项目成员】，还可能有非项目的工时项，也要安排成员。
2023-03-01归属地：湖南
铿然有点复杂，先把业务需求和场景说清楚再展开设计更容易理解，否则要么不理解，要么会觉得是过度设计。2023-06-20归属地：江苏
aoe工时管理依赖的上下文真多啊，有：基础信息管理、项目管理、假期管理2023-02-28归属地：浙江
收起评论
