领域驱动设计（Thoughtworks洞见）

二零二零年读完的第二十四本，对书中讲到的点都特能感同身受，提到的很多建议都在工作中不断提炼，但是可惜在公司中并没有同样对这个感兴趣的同事可以参与讨论，有时候我知道问题的症结跟解决方法但是要往前推的时候并不是那么容易解析清楚，或许还是那句话“道可道，非常道”坑是要躺过才知道怎么爬。在技术方面上，我在架构上都已经买好了演进的种子，在上层把控好这个服务便捷跟把领域边界限定好了，整体就可控了。最后，继续实践技术总结。

怎么说呢，给了推荐，毕竟还是能从里面学到东西。但是 Thoughtworks 的各种对外的书籍，都是一眼有道理，再看不给看的感觉，经常就是结论之后里面空空，可能跟他们公司的性质有关系，一般来说后面的内容就属于付费咨询了，大概就是文字给你希望，付费帮你落地。

最近正在学习DDD对项目进行拆分，这本书确实给了我一些启示。 从理论出发落于实践也许是最好的教学方式，我认为这本书没有。 书中的某些理论确实值得学习和思考，但是有很多是作者by experience的总结。难以说放在四海皆准。 收集文章组成的书连贯性不好，某些篇幅索然无味。 更多的告诉读者what，而没有着重说明how和why，这让读者很难将理论落地。 不过笔记我仍然会试试翻看。

去年工作中重点研究的一个方向就是领域驱动，我对领域驱动的认识从云里雾里到开始有感觉。这本书的很多理念和方法讲的比较通俗且具备实操性，今年项目上希望能借鉴起来改善项目提高质量~

本书是一些文章的拼凑，内容不够系统，预设了很多DDD前提知识，需要读者具备一定的理论基础和实践经验才能理解作者们分享的心得。

当敏捷宣言的17位签署者在2001年喊出“响应变化胜于遵循计划”这样的口号时，鲜有组织会真正把这句话当回事儿，甚至很多经验丰富的管理者会认为好的计划是成功的一半，遵循计划就是另外一半。然而在时下的第四次工业革命浪潮中，可能很多管理者已经不会简单满足于“响应”，而是选择主动发起变化了。不确定性管理成了这个时代的主旋律，企业的响应力成了成败的关键。 随着这种趋势的深入，架构设计这个技术管理领域也被推到了风暴边缘。“稳定”这个过去我们用来形容好系统的词语似乎已经失去原有的含义，很多人开始用“健壮”这个词语来形容好的系统。比如Netflix公司采用的Chaos Monkey机制随机主动关停线上服务而不会造成整个服务生态宕机的作法更多的是在测试系统的健壮性，保证不会因为某个局部的问题而造成全身瘫痪。 然而架构的健壮性却比较难于定义和测试，以至于很多时候咱们在架构设计上还是在追求稳定性。在一个典型的企业IT组织里，当你询问一位资深工程师架构设计时，往往会得到一张搭积木一样的“架构图”。 图的底层是各种数据存储（从经典的Oracle到大数据标配的Hadoop），图的中间是类似Kafka这样的消息管道和传统的ESB（消息总线），上层则是各种业务应用（包括各种Web应用和移动的APP）。 仿佛这是一个流行的“稳定”架构设计。

从业务出发、面向业务变化是我们现代架构设计成功的关键。架构设计的核心实质是保证面对业务变化时我们能够有足够快的响应能力。

TW作为DDD领域的持续推动者, 本书算不上一本领域驱动的入门书, 但非常推荐有一定业务架构基础, 准备尝试领域驱动具体落地的实践者好好的看看这本书, 这里类似一个大杂烩收集了很多领域驱动的信息, 把过往的文章信息做了一次整合. 其中四色建模法提供了一个非常形象的例子. 建议先去了解一定基础概念再来看这本书.

书全名叫领域驱动设计，但只是收录了各种文章，没有体系化的介绍和思考，也没没有自身的核心观点

本书实质上是一些博客合集，作为想了解领域模型是怎么回事，还是很有帮助的。里面提到两个领域模型的实践方法，还是让人眼前一亮的。当然，领域驱动设计要做好，还是尽可能找机会去实践推演，，可以结合自己现有业务系统去推演，不断历练自己设计思维，提升领域设计能力。 对作者提到的一个观点也很是认同，作为技术人员，不能单纯关注技术维度，也需要去关注下业务价值，毕竟技术和业务密不可分。最后提到的技术债也是感同身受，作为一名程序员，尽量不要欠小的技术债。