书籍介绍
这不是一本教你怎么写代码的架构书，而是一场关于“软件究竟在做什么”的争论。它反复逼问一个让人不适的问题：软件开发本身就是设计，凭什么把建模交给少数资深工程师、把实现丢给低技能劳动力？书中把全部重心压在“领域”二字上——所谓领域，其实就是业务。它劝告开发者：那些为了能力可迁移而追逐的通用技术，最终实现价值的却是业务本身。读者反馈两极分化：有人苦于翻译生硬、例子业务性过强，读两遍仍摸不着头脑；也有人视之为“史诗级”，认为技术会过时，但这种把规范化概念注入设计的思想不会。它适合在重构或设计复杂系统时边做边读，若当作理论消遣，大概率会睡着。
AI导读
核心看点
- 阐述应对软件核心复杂性的系统化方法
- 提出通用语言模式，统一团队沟通术语
- 定义实体、值对象等核心建模构建块
读者共识
- 软件工程经典之作，重塑设计思维
- 阅读门槛高，需反复研读并实践
- 翻译质量参差，部分概念理解困难
精彩摘录
- "当人们学习设计技术时，各种可能性令他们兴奋不已，然而真实项目的错综复杂又会为他们泼一盆冷水"
- "当你遇到一个杂乱无章的大系统时，应该从哪里入手呢？在 XP 社区中，答案往往是以下之一： 1. 可以从任何地方开始，因为所有的东西都要重构； 2. 从影响你工作的那部分开始——也就是完成具体任务所需要的那个部分； 这两种做法我都不赞成。第一种做法并不可行，只有少数完全由顶尖的程序员组成的团队才是例外。第二种做法往往只是对外围问题进行了处理，只治标而不治本，回避了最严重的问题。最终这会使得代码变得越来越难以重构。 因此，如果你既不能全面解决问题，又不能“哪儿痛治哪儿”，那么该怎么办呢？ 1. 如果采用“哪儿痛治哪儿”这种重构策略，要观察一下根源问题是否涉及 core domain 或 core "
- "人们总是把软件开发比喻成制造业。这个比喻的一个推论是：经验丰富的工程师做设计工作，而技能水平较低的劳动力负责组装产品。这种做法使许多项目陷入困境，原因很简单——软件开发就是设计。"
- "由于应用层负责对领域对象的行为进行协调，因此细粒度的领域对象可能会把领域层的知识泄露到应用层中。这产生的结果是应用层不得不处理复杂的、细致的交互，从而使领域知识蔓延到应用层或用户界面代码中，而领域层会丢失这些知识。"
- "用户界面/展现层 负责向用户展现信息以及解释用户命令。 应用层 很薄的一层，用来协调应用的活动。它不包含业务逻辑。它不保留业务对象的状态，但它保有应用任务的进度状态。 领域层 本层包含关于领域的信息。这是业务软件的核心所在。在这里保留业务对象的状态，对业务对象和它们状态的持久化被委托给了基础设施层。 基础设施层 本层作为其他层的支撑库存在。它提供了层间的通信，实现对业务对象的持久化，包含对用户界面层的支撑库等作用。"
- "当开始编写软件的时候，其实我们所知甚少。"
- "高效率的团队，需要有意识地积累知识，并持续学习。"
- "如果文档的角色不太重要，那么总是将它更新为最新状态，将是劳动力的浪费。"
目录
用户评论
这本书不仅仅是各种“模式语言”的列举，还提出了软件开发中的一些“洞见”，读后令人印象深刻。
从大学读到现在才读完的一本书…这本书不是教抽象抽象再抽象，而是传扬规范化领域概念并引入到软件设计中的一种思想。其实现在已经是很普遍的做法了…
好难读懂
太形而上了。很多章节把简单的事物说得很复杂，就像是用哲学理论教人走路
这书要常读
关于研发的理论心得，领域即将一个软件系统的核心业务功能集中在一个核心域里面，其中包含了实体、值对象、领域服务、资源库和聚合等概念。从产品视角来看，就是功能域，将相关同类型功能集合在一起，功能域之间互相联结、各自独立。
2022年春节通读了一遍这本书，并且录了音做成了视频，地址是：https://www.bilibili.com/video/BV11S4y1G7Gh/ 因为是精读，所以对他里面每一个章节我都写了自己的想法。
这么说吧，书中的例子还是挺好的，有些例子细想一下确实挺有意思的，而且能够得到一些启发。然而大部分还是比较文绉绉的，而且有时候看不懂。 我觉得是翻译的问题，能明显的感觉出来是不同的翻译翻译的。
很抽象，有点哲学的味道，从道来讲软件设计，确实拔高了眼界，但难理解，需要多读几遍。几个名词，敏捷开发，面向对象，统一语言，模型驱动设计。
下载
收藏