作品简介

当敏捷宣言的17位签署者在2001年喊出“响应变化胜于遵循计划”这样的口号时,鲜有组织会真正把这句话当回事儿,甚至很多经验丰富的管理者会认为好的计划是成功的一半,遵循计划就是另外一半。然而在时下的第四次工业革命浪潮中,可能很多管理者已经不会简单满足于“响应”,而是选择主动发起变化了。不确定性管理成了这个时代的主旋律,企业的响应力成了成败的关键。

随着这种趋势的深入,架构设计这个技术管理领域也被推到了风暴边缘。“稳定”这个过去我们用来形容好系统的词语似乎已经失去原有的含义,很多人开始用“健壮”这个词语来形容好的系统。比如Netflix公司采用的Chaos Monkey机制随机主动关停线上服务而不会造成整个服务生态宕机的作法更多的是在测试系统的健壮性,保证不会因为某个局部的问题而造成全身瘫痪。

然而架构的健壮性却比较难于定义和测试,以至于很多时候咱们在架构设计上还是在追求稳定性。在一个典型的企业IT组织里,当你询问一位资深工程师架构设计时,往往会得到一张搭积木一样的“架构图”。

图的底层是各种数据存储(从经典的Oracle到大数据标配的Hadoop),图的中间是类似Kafka这样的消息管道和传统的ESB(消息总线),上层则是各种业务应用(包括各种Web应用和移动的APP)。仿佛这是一个流行的“稳定”架构设计。

作品目录

  • 综述
  • DDD战略篇:架构设计的响应力
  • 什么是架构设计?
  • 面向业务变化而架构
  • 打造架构响应力的方法
  • DDD战术篇:领域模型的应用
  • 业务对象的抽象
  • 聚合的封装
  • 领域服务的定义
  • Repositories的使用
  • 限界上下文的意义
  • 战术建模小结
  • DDD实战篇:分层架构的代码结构
  • 分层架构
  • 模型表达
  • 依赖关系
  • 测试实现
  • 关于预先设计
  • DDD的终极大招——By Experience
  • 问题、问题、问题
  • 跨领域合作
  • 从需求到代码
  • 刻意“失败”
  • 写在最后
  • 通用语言、领域、限界上下文
  • 重读领域驱动设计——如何说好一门通用语言
  • 初尝“通用语言”
  • “通用语言”遇到同名词汇时就变得不清不楚了
  • 通过添加约束消除歧义
  • 来解决下前文的问题
  • 当Subdomain遇见Bounded Context
  • 区分问题和解决方案是个老大难问题
  • 区分Subdomain的必要性
  • Subdomain和Bounded Context的对应关系?
  • 坚持持续认知问题
  • 架构
  • 从三明治到六边形
  • 软件项目的套路
  • 复杂的业务
  • 层次架构(三明治)
  • 前后端分离
  • 业务与基础设施分离
  • 六边形架构(端口适配器)
  • 小结
  • 端口和适配器架构——DDD好帮手
  • 什么是端口和适配器架构
  • 端口和适配器架构有什么好处
  • 与领域驱动设计的协同增效
  • 让“DDD战略设计”指导隔离实施
  • 总结
  • 领域事件
  • 识别领域事件
  • 1.组织没有领域专家
  • 2.面向复杂业务系统的事件风暴
  • 3.业务代表或领域专家用自己的语言表达业务
  • 4.事件风暴可能识别不出来所有领域事件
  • 总结
  • 在微服务中使用领域事件
  • 认识领域事件
  • 事件风暴(Event Storming)
  • 创建领域事件
  • 发布领域事件
  • 业务操作和事件发布的原子性
  • 总结
  • 当提到“事件驱动”时,我们在说什么?
  • 事件通知
  • 事件携带的状态转移(Event-Carried State Transfer)
  • 事件溯源
  • CQRS
  • 理解这些模式
  • 微服务
  • DDD & Microservices
  • 服务于更高的业务响应力
  • 从业务视角分离复杂度
  • 业务和技术渐进统一的架构设计
  • 跨职能协作的架构设计
  • 永无终止的DDD和演进的Microservices
  • 你需要成为那个高个子!
  • 服务拆分与架构演进
  • 前言
  • 我们项目架构的演化历程
  • 问题1:如何将单体结构拆分为服务化架构?
  • 问题2:拆分后业务变了增加了怎么办?
  • 问题3:如何安全地持续地拆?
  • 真正有挑战的问题4:如何保证拆对了?
  • 总结
  • 溯源微服务:企业分布式应用的一次回顾
  • 我们在重新界定抽象边界上取得了进展…
  • RPC?不,是API!
  • 技术组件?不,是业务服务!
  • 解耦服务就足够了吗?我们需要去中心化一切!
  • 我们干得还不错,但也在持续搞砸一些事情…
  • 如何更进一步
  • 示例实现
  • 后端开发实践系列——开发者的第0个迭代
  • 第一步:从写好README开始
  • 一键式本地构建
  • 目录结构
  • 基于业务分包
  • 自动化测试分类
  • 日志处理
  • 异常处理
  • 后台任务与分布式锁
  • 统一代码风格
  • 静态代码检查
  • 健康检查
  • API文档
  • 数据库迁移
  • 多环境构建
  • CORS
  • 常用第三方类库
  • 总结
  • 后端开发实践系列:领域驱动设计(DDD)编码实践
  • DDD总览
  • 实现业务的3种常见方式
  • 基于业务的分包
  • 领域模型的门面——应用服务
  • 业务的载体——聚合根
  • 实体vs值对象
  • .聚合根的家——资源库
  • 创生之柱——工厂
  • 必要的妥协——领域服务
  • Command对象
  • DDD中的读操作
  • 总结
  • 后端开发实践系列:事件驱动架构(EDA)编码实践
  • 第一部分:领域事件的建模
  • 第二部分:基于RabbitMQ的示例项目
  • 系统演示
  • 总结
  • 后端开发实践系列:简单可用的CQRS编码实践
  • 一个例子
  • CQRS实现模式概览
  • 关于Representation对象的命名
  • 什么时候该采用CQRS
  • 总结
  • 用DDD实现打卡系统
  • 案例1.一家咨询服务公司的Timesheet系统
  • 问题空间与子域
  • 如何划分上下文
  • 扩展阅读
  • DDD该如何学?
  • 领域驱动设计(DDD)实现之路
  • 总结
  • 从“四色建模法”到“限界纸笔建模法”
  • “小画笔”绘画课外班
  • 用“四色建模法”进行建模
  • 用“限界纸笔建模法”进行建模
  • 限界纸笔建模法的3点优势
  • 总结
  • 可视化架构设计—C4介绍
  • 四张核心图·系统上下文图
  • 三张扩展图
  • 为什么C4值得推荐
  • 总结
  • 从架构可视化入门到抽象坏味道
  • 抽象的坏味道
  • 合成更大的元素
  • 画一些共识图来忽略掉一些通用的元素
  • 通过制定主题,限制文字的抽象层次
  • 只画重要的图,剩下的交流的时候再画
  • 总结
  • 技术债治理的四条原则
  • 技术债全景图
  • 技术债治理的困境
  • 技术债治理的四条原则
  • TthoughtWorks著书/译书
  • 《ThoughtWorks技术雷达》
展开全部