如何落地业务建模
徐昊
ThoughtWorks中国区CTO
新⼈⾸单¥59.9
1766 人已学习
课程目录
已更新 7 讲 / 共 22 讲
0/2登录后，你可以任选2讲全文学习。
开篇词 (1讲)
开篇词｜为什么你需要学习业务建模？
免费
旧约：“前云时代”的领域驱动设计 (6讲)
01｜领域驱动设计到底在讲什么？
02｜统一语言是必要的吗？
03｜我们要怎么理解领域驱动设计？
04｜跨越现实的障碍（1）：要性能还是要模型？
05｜跨越现实的障碍（2）：富含知识还是代码坏味道？
06 | 跨越现实的障碍（3）：架构分层就对了吗？
06 | 跨越现实的障碍（3）：架构分层就对了吗？
徐昊 2021-07-06
你好，我是徐昊。今天我们来聊聊如何有效地基于领域模型构造合理的架构。
到目前为止，我们学会了通过关联对象解决聚合 / 关联关系；利用角色对象分离不同上下文中的交互；并使用上下文对象完成实体对象到角色对象的扮演。这些模式通过结构上的优化，更好地组织了对核心数据的访问逻辑，使得我们可以在兼顾架构约束的同时，将领域概念与逻辑有效地转化为领域模型。
然而当我们把眼光从构造领域模型，扩展到利用领域模型构建整个应用或系统时，就会遇到新的问题：如何组织领域逻辑与非领域逻辑，才能避免非领域逻辑对模型的污染？
通常我们会使用分层架构（Layered Architecture）区分不同的逻辑以解决这个问题。然而由于领域层被人为赋予了最稳定的特性，破坏了分层架构间的依赖关系。所以我们需要修正分层，才能有效地围绕领域模型来构造软件架构。
那么今天这节课我们就看看分层架构的问题在哪儿，以及如何通过能力供应商（Capability Provider）模式获得一个更好的架构愿景。
领域层的“不正当关系”
分层架构是运用最为广泛的架构模式，它将不同关注点的逻辑封装到不同的层中，以便扩展维护，同时也能有效地控制变化的传播。
在使用领域驱动设计时，我们通常会将系统分成四层：
确认放弃笔记？
放弃后所记笔记将不保留。
新功能上线，你的历史笔记已初始化为私密笔记，是否一键批量公开？
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《如何落地业务建模》，如需阅读全部文章，
请订阅文章所属专栏，新⼈⾸单¥59.9
请订阅文章所属专栏，新⼈⾸单¥59.9
立即订阅
登录 后留言
精选留言(2)
威为什么说支付失败的回访是应用层逻辑，而不是领域层逻辑呢，这里的划分是有什么准则吗2021-07-06
koofrank支付的例子里，邮件通知，本身作为基础设计来实现，然后业务变化还希望触发支付失败回访，这时属于应用层，那现在是不是领域层依赖了两个客服service，还是把之前发邮件也放到了应用层，怎么组合这两个呢2021-07-06
收起评论