如何落地业务建模
徐昊
ThoughtWorks中国区CTO
新⼈⾸单¥59.9
1766 人已学习
课程目录
已更新 7 讲 / 共 22 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词|为什么你需要学习业务建模?
免费
旧约:“前云时代”的领域驱动设计 (6讲)
01|领域驱动设计到底在讲什么?
02|统一语言是必要的吗?
03|我们要怎么理解领域驱动设计?
04|跨越现实的障碍(1):要性能还是要模型?
05|跨越现实的障碍(2):富含知识还是代码坏味道?
06 | 跨越现实的障碍(3):架构分层就对了吗?
如何落地业务建模
15
15
1.0x
00:00/00:00
登录|注册

06 | 跨越现实的障碍(3):架构分层就对了吗?

你好,我是徐昊。今天我们来聊聊如何有效地基于领域模型构造合理的架构。
到目前为止,我们学会了通过关联对象解决聚合 / 关联关系;利用角色对象分离不同上下文中的交互;并使用上下文对象完成实体对象到角色对象的扮演。这些模式通过结构上的优化,更好地组织了对核心数据的访问逻辑,使得我们可以在兼顾架构约束的同时,将领域概念与逻辑有效地转化为领域模型。
然而当我们把眼光从构造领域模型,扩展到利用领域模型构建整个应用或系统时,就会遇到新的问题:如何组织领域逻辑与非领域逻辑,才能避免非领域逻辑对模型的污染
通常我们会使用分层架构(Layered Architecture)区分不同的逻辑以解决这个问题。然而由于领域层被人为赋予了最稳定的特性,破坏了分层架构间的依赖关系。所以我们需要修正分层,才能有效地围绕领域模型来构造软件架构
那么今天这节课我们就看看分层架构的问题在哪儿,以及如何通过能力供应商(Capability Provider)模式获得一个更好的架构愿景。

领域层的“不正当关系”

分层架构是运用最为广泛的架构模式,它将不同关注点的逻辑封装到不同的层中,以便扩展维护,同时也能有效地控制变化的传播。
在使用领域驱动设计时,我们通常会将系统分成四层:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
该试读文章来自付费专栏《如何落地业务建模》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥59.9
立即订阅
登录 后留言

精选留言(2)

  • 为什么说支付失败的回访是应用层逻辑,而不是领域层逻辑呢,这里的划分是有什么准则吗
    2021-07-06
  • koofrank
    支付的例子里,邮件通知,本身作为基础设计来实现,然后业务变化还希望触发支付失败回访,这时属于应用层,那现在是不是领域层依赖了两个客服service,还是把之前发邮件也放到了应用层,怎么组合这两个呢
    2021-07-06
收起评论
2
返回
顶部