如何落地业务建模
徐昊
ThoughtWorks中国区CTO
新⼈⾸单¥59.9
2074 人已学习
课程目录
已更新 11 讲 / 共 22 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词|为什么你需要学习业务建模?
免费
旧约:“前云时代”的领域驱动设计 (10讲)
01|领域驱动设计到底在讲什么?
02|统一语言是必要的吗?
03|我们要怎么理解领域驱动设计?
04|跨越现实的障碍(上):要性能还是要模型?
05|跨越现实的障碍(中):富含知识还是代码坏味道?
06 | 跨越现实的障碍(下):架构分层就对了吗?
07|统一语言可以是领域模型本身吗?
08 | 什么办法可以在讨论中自然形成统一语言?
09|怎么才能更有效地获得事件流?
10 | 将模型实现为RESTful API(上)
如何落地业务建模
15
15
1.0x
00:00/00:00
登录|注册

10 | 将模型实现为RESTful API(上)

你好,我是徐昊。今天我们来聊聊如何将模型映射为 RESTful API。
通过前面九节课的学习,你应该已经学会了如何通过几种设计模式避免架构约束对模型的影响(4-6 节),也学会了几种不同的建模方法以构造业务模型(7-9 节)。然而我们之前讲的内容,主要的着眼点在于如何获得模型,以及如何组织代码。接下来,就是通过模型获得 API,从而将模型作为业务能力,暴露给其他消费者调用。
在前面的课程中,我们一直都在强调领域驱动设计受到行业热捧的一个原因:寻找到一个在软件系统生命周期内稳固的不变点,由它构成架构、协同与交流的基础,帮助我们更好地应对软件中的不确定性
API 作为对外暴露的接口,也是需要保持高稳定性的组件。我们希望 API 最好能像领域模型一样稳定。于是通过领域模型驱动获得 API 的设计(Domain Model Driven API Design),就成了一种非常自然的选择。
那么今天我们就来讲一讲怎样构建领域驱动的 API 设计,以及为何我们会选用 RESTful API。

什么风格的 API 适合作为模型 API?

想要实现领域模型驱动 API 并不困难,但是我们需要选择恰当的 API 风格:要从数据角度,而不要从行为角度去构建 API,以保证构建的 API 能够和领域模型结合得更加紧密。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
该试读文章来自付费专栏《如何落地业务建模》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥59.9
立即订阅
登录 后留言

精选留言(3)

  • 我有个疑问,像GET /users/{user_id}/subscriptions,这个api只要我知道user id,是不是就可以看任意的用户的订阅了?安全性怎么保证呢
    2021-07-15
  • 不同的格式是什么意思?json or xml?如果指的是这个的话,可以通过Content-Type协商
    2021-07-15
  • Oops!
    HTTP常用的方法就get put post delete patch, 实际业务中对一个资源对象的操作可能超过5种,api的body的报文结构如何设计,才能避免api退化成混合了rpc风格的api呢?如修改文章内容,可能修改文章的body,也可能是修改文章标题,都用put, 请求的body怎么设计更符合面向对象的范式呢?

    作者回复: 下一节

    2021-07-15
    1
收起评论
3
返回
顶部