封面
版权信息
综述
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技术雷达》
更新时间：2020-06-10 15:27:10
完结共170章
倒序