领域驱动设计（Thoughtworks洞见）

领域驱动设计（Thoughtworks洞见）读书笔记模板01思维导图读书笔记目录分析内容摘要精彩摘录作者介绍目录0305020406思维导图驱动设计图消息计划时鲜标配业务领域架构问题事件服务对象技术系统代码总结架构设计本书关键字分析思维导图内容摘要内容摘要当敏捷宣言的17位签署者在2001年喊出“响应变化胜于遵循计划”这样的口号时，鲜有组织会真正把这句话当回事儿，甚至很多经验丰富的管理者会认为好的计划是成功的一半，遵循计划就是另外一半。然而在时下的第四次工业革命浪潮中，可能很多管理者已经不会简单满足于“响应”，而是选择主动发起变化了。不确定性管理成了这个时代的主旋律，企业的响应力成了成败的关键。图的底层是各种数据存储（从经典的Oracle到大数据标配的Hadoop），图的中间是类似Kafka这样的消息管道和传统的ESB（消息总线），上层则是各种业务应用（包括各种Web应用和移动的APP）。仿佛这是一个流行的“稳定”架构设计。读书笔记读书笔记从业务出发、面向业务变化是现代架构设计成功的关键。这本书比较适合已经有DDD基础的架构师或工程师进行阅读，有不少实践过程中的思考和示例，能够让你更好的理解DDD应该如何在进行落地。适合有一定领域驱动设计基础的开发，架构人员阅读，落地DDD时推荐阅读。最近正在学习DDD对项目进行拆分，这本书确实给了我一些启示。更多的告诉读者what，而没有着重说明how和why，这让读者很难将理论落地。总体不错，理论+实践相结合，其中有很多可实际落地的东西，例如:领域事件，聚合，面对复杂查询时，到底是按照数据模型查询还是按照领域模型设计，其中的利弊分析的很透彻。文章集合，大部分人的观点都有可学习的价值，很多从实际出发的案例值得去参考。去年工作中重点研究的一个方向就是领域驱动，我对领域驱动的认识从云里雾里到开始有感觉。非常不推荐，整本书完全就是博客合集，整理了一些人在使用DDD或者初学DDD的过程中写的内容，有的文章晦涩无示例，有的文章似乎要刚开始讲DDD然后就莫名结束了。精彩摘录精彩摘录软件架构设计的实质是让系统能够更快地响应外界业务的变化，并且使得系统能够持续演进从业务出发、面向业务变化是我们现代架构设计成功的关键。架构设计的核心实质是保证面对业务变化时我们能够有足够快的响应能力。1．让团队中各个角色（从业务到开发测试）都能够采用统一的架构语言，从而避免组件划分过程中的边界错位。2．让业务架构和系统架构形成绑定关系，从而建立针对业务变化的高响应力架构。面向业务变化而架构就要求首先理解业务的核心问题，即有针对性地进行**点分离来找到相对内聚的业务活动形成子问题域。子问题域内部是相对稳定的，即未来的变化频率不会很高，而子问题边界是很容易变化的通过组件化完成**点分离从而降低局部复杂度识别聚合是认知潜在核心业务规则的过程，而定义出来的聚合是在大家共识基础上对核心业务规则的封装。值得注意的是，不要把Entity的属性和行为分离到Domain和Service两层中去实现，即所谓的贫血模型，事实证明这样的实现方式会造成很大的维护问题。子域subdomain和限界上下文某种意义上是互相印证的，重点在区分问题域和解决方案域，这是落地DDD最困难的地方，也是判断一个架构师能力进阶的分水岭。目录分析DDD战略篇：架构设计的响应力DDD战术篇：领域模型的应用DDD实战篇：分层架构的代码结构DDD的终极大招——ByExperience综述DDD战略篇：架构设计的响应力什么是架构设计？面向业务变化而架构打造架构响应力的方法DDD战术篇：领域模型的应用业务对象的抽象聚合的封装领域服务的定义Repositories的使用限界上下文的意义战术建模小结DDD实战篇：分层架构的代码结构分层架构模型表达依赖关系测试实现关于预先设计DDD的终极大招——ByExperience问题、问题、问题跨领域合作从需求到代码刻意“失败”写在最后当Subdomain遇见BoundedContext重读领域驱动设计——如何说好一门通用语言通用语言、领域、限界上下文重读领域驱动设计——如何说好一门通用语言初尝“通用语言”“通用语言”遇到同名词汇时就变得不清不楚了通过添加约束消除歧义来解决下前文的问题当Subdomain遇见BoundedContext区分问题和解决方案是个老大难问题区分Subdomain的必要性Subdomain和BoundedContext的对应关系？坚持持续认知问题端口和适配器架构——DDD好帮手从三明治到六边形架构从三明治到六边形软件项目的套路复杂的业务层次架构（三明治）前后端分离业务与基础设施分离六边形架构（端口适配器）小结端口和适配器架构——DDD好帮手什么是端口和适配器架构端口和适配器架构有什么好处与领域驱动设计的协同增效让“DDD战略设计”指导隔离实施总结识别领域事件当提到“事件驱动”时，我们在说什么？在微服务中使用领域事件领域事件识别领域事件1．组织没有领域专家2．面向复杂业务系统的事件风暴3．业务代表或领域专家用自己的语言表达业务4．事件风暴可能识别不出来所有领域事件总结在微服务中使用领域事件认识领域事件事件风暴（EventStorming）创建领域事件发布领域事件业务操作和事件发布的原子性总结当提到“事件驱动”时，我们在说什么？事件通知事件携带的状态转移（Event-CarriedStateTransfer）事件溯源CQRS理解这些模式DDD&Microservices溯源微服务：企业分布式应用的一次回顾服务拆分与架构演进微服务DDD&Microservices服务于更高的业务响应力从业务视角分离复杂度业务和技术渐进统一的架构设计跨职能协作的架构设计永无终止的DDD和演进的Microservices你需要成为那个高个子！服务拆分与架构演进我们项目架构的演化历程问题1：如何将单体结构拆分为服务化架构？问题2：拆分后业务变了增加了怎么办？问题3：如何安全地持续地拆？真正有挑战的问题4：如何保证拆对了？总结溯源微服务：企业分布式应用的一次回顾我们在重新界定抽象边界上取得了进展…RPC？不，是API！技术组件？不，是业务服务！解耦服务就足够了吗？我们需要去中心化一切！我们干得还不错，但也在持续搞砸一些事情…如何更进一步后端开发实践系列——开发者的第0个迭代后端开发实践系列：领域驱动设计（DDD）编码实践后端开发实践系列：事件驱动架构（EDA）编码实践后端开发实践系列：简单可用的CQRS编码实践示例实现用DDD实现打卡系统领域驱动设计（DDD）实现之路DDD该如何学？示例实现从“四色建模法”到“限界纸笔建模法”可视化架构设计—C4介绍从架构可视化入门到抽象坏味道技术债治理的四条原则示例实现后端开发实践系列——开发者的第0个迭代第一步：从写好README开始一键式本地构建目录结构基于业务分包自动化测试分类日志处理异常处理后台任务与分布式锁统一代码风格后端开发实践系列：领域驱动设计（DDD）编码实践DDD总览实现业务的3种常见方式基于业务的分包领域模型的门面——应用服务业务的载体——聚合根实体vs值对象·聚合根的家——资源库创生之柱——工厂必要的妥协——领域服务后端开发实践系列：事件驱动架构（EDA）编码实践第一部分：领域事件的建模第二部分：基于RabbitMQ的示例项目系统演示总结后端开发实践系列：简单可用的CQRS编码实践一个例子CQRS实现模式概览关于Representation对象的命名什么时候该采用CQRS总结用DDD实现打卡系统案例1．一家咨询服务公司的Timesheet系统问题空间与子域如何划分上下文领域驱动设计（DDD）实现之路总结从“四色建模法”到“限界纸笔建模法”“小画笔”绘画课外班用“四色建模法”进行建模用“限界纸笔建模法”进行建模限界纸笔建模法的3点优势总结可视化架构设计—C4介绍四张核心图·系统上下文图三张扩展图为什么C4值得推荐总结从