书籍介绍
本书作者是当今面向对象软件开发的权威，他在一组专家级合作者的帮助下，将40多种经常出现的解决方案转化成模式，最终写成这本能够应用于任何一种企业应用平台的、关于解决方案的、不可或缺的手册。本书获得了2003年度美国软件开发杂志图书类的生产效率奖和读者选择奖。本书分为两大部分。第一部分是关于如何开发企业应用的简单介绍。第二部分是本书的主体，是关于模式的详细参考手册，每个模式都给出使用方法和实现信息，并配以详细的Java代码或C#代码示例。此外，整本书中还用了大量UML图来进一步阐明有关概念。
本书是为致力于设计和构建企业应用的软件架构师、设计人员和编程人员而写的，同时也可作为高等院校计算机专业及软件学院相关课程的参考教材。
作者简介
Martin Fowler 是一位独立咨询顾问，他运用对象技术解决企业问题已经超过十年。他的顾问领域包括健康管理、金融贸易，以及法人财务。他的客户包括 Chrysler、Citibank、UK National Health Service、Andersen Consulting、Netscape Communications。此外 Fowler 也是 objects、UML、patterns 技术的一位合格讲师，他是《AnalysisPatterns》和《UML Distilled》的作者。
AI导读
核心看点
- 本书系统阐述了企业级应用架构的核心模式，涵盖分层架构、领域逻辑组织、ORM映射及Web表现层设计。作者Martin Fowler深入剖析了对象与关系数据库映射的复杂性，详细对比了简单领域模型与复杂领域模型，并提供了数据映射器等关键模式的实现原理，帮助读者理解ORM框架底层逻辑。
- 书中对并发控制、事务管理及会话状态的处理提供了严谨的工程指导。作者明确区分了乐观锁与悲观锁的适用场景，强调在业务事务中优先使用乐观锁，并深入探讨了分布式环境下的远程调用限制，指出细粒度接口在远程场景下的性能陷阱，倡导使用粗粒度接口以减少网络开销。
- 尽管部分技术细节随时代演进已融入现代框架，但书中关于架构设计原则、系统解耦及安全性考虑的论述依然具有极高的理论价值。它揭示了构建复杂系统时如何平衡正确性与灵活性，以及如何通过合理的架构分层来应对不断变化的业务需求，是理解软件工程本质的重要文献。
读者共识
- 读者普遍认为本书是软件架构领域的经典之作，其核心思想已融入现代开发框架。虽然具体技术细节因时代变迁而显得陈旧，但其对系统分层、数据映射、并发安全等问题的深入剖析依然具有极高的指导意义，是理解现代企业级应用架构底层逻辑的必读文献。
- 多数读者指出书中部分代码示例和特定技术（如旧版EJB）已过时，直接参考价值降低。然而，大家一致认可其在架构设计原则、模式滥用警示及系统安全性方面的深刻见解。许多读者表示，在阅读完本书后，对Spring、Hibernate等框架的设计原理有了更本质的理解，提升了代码质量。
- 读者强烈建议初学者谨慎阅读，因其内容晦涩且部分概念与现代实践脱节。但对于有经验的开发者，本书是提升架构视野、理解系统复杂性本质的重要资源。大家共识认为，不应拘泥于书中的具体实现，而应学习其分析问题、权衡利弊及构建健壮系统的思维方式，这对长期职业发展大有裨益。
精彩摘录
- "任何对象可能作为远程对象使用时，经常需要一个粗粒度的接口来减少完成某些任务所需要的调用次数。这不仅会影响你的方法调用，同样还会影响你的对象。现在，一个调用中就会包括访问和更改订单及订单的功能，而不会像以前那样分开调用，这会完全影响你的对象结构。你将不得不放弃小粒度对象和小粒度方法带来的清晰意图和小粒度控制所带来的好处。编程变得困难，并且会使生产率下降。"
- "一个远程外观是一个粗粒度的外观（facade），它建立在大量的细粒度对象之上。所有细粒度对象都没有远程接口，并且远程外观不包括领域逻辑。远程外观所要完成的功能是把粗粒度的方法转换到低层的细粒度对象上。 任何外观都应该是一层薄薄的皮肤并且只负责很小一部分责任。"
- "远程外观这种模式意味着同步。"
- "为别人提供服务的接口和使用别人服务的接口存在较大的差别，需要明确区分。这就是表现层和数据层相对于核心的本质差别"
- "合并了行为和数据的领域的模型。 领域模型衍生出两种风格。简单领域模型看起来和数据库设计很类似，这种设计中几乎每一个数据库表都与一个领域对象对应。而复杂领域模型则与数据库设计不同，它使用继承、策略和其他设计模式，是一张由互联的细粒度对象组成的复杂网络。复杂领域模型更适合复杂的逻辑，但它到数据库的映射比较困难。简单领域模型可以使用活动记录，而复杂领域模型需要使用数据映射器。"
- "对于任何并发的本质来说，仅仅考虑正确性是不够的，还必须考虑灵活性（即有多少并发活动可以同时进行）。人们常常需要牺牲一些正确性以获取更多的灵活性，这取决于失败的严重性和可能性以及人们对并发处理数据的需求。"
- "依我们看来，使用每会话一进程有很多可说之处。尽管每会话一进程没有每会话一线程的效率高，但它们有相同的可伸缩性。而且有更好的健壮性——如果某个现成崩溃了，可能会导致整个进程垮掉，但是使用每会话一进程能限制这种破坏。特别是对经验较少的开发者们，用硬件代价来避免处理线程的麻烦（包括修复bug所用的时间和代价）是值得的。事实上，很少有人真正做过性能测试来估算他们在应用中使用每会话一线程和每会话一进程的代价。"
- "10.4 数据映射器(Data Mapper) 在保持对象和数据库(以及映射器本身)彼此独立的情况下在二者之间移动数据的一个映射层。 对象和关系数据库用来组织数据的机制不同。对象很多部分（如集合和继承）在关系数据库中不存在。当创建一个具有大量业务逻辑的对象模型时，有必要采用这些机制更好地组织它的数据和行为。如此一来便产生了不同的方案，也就是说对象方案和关系方案不相配。 数据映射器时分离内存对象与数据库的一个软件层。其职责时在内存对象与数据库之间传递数据并保持它们彼此独立。有了数据映射器，内存对象甚至不需要知道数据库的存在；它们也不需要SQL接口代码，当然也不需要知道数据库方案。 数据映射器的主"
目录
用户评论
这本书可以买， 但千万别买这一版， 翻译能让你把本来一周读完的书， 加上你审校英文的工作量， 半年都tm看不完， 还白生一阵闷气。 以后这译者和带 umlchina 审校的还是不碰了
终于读完了这本经典。。。
毁在翻译。另求他书
实践后的深刻总结
10几年前的书，很多都过时了。
太老了吧这本书。。。那么多数据库的玩意儿。。。
草草扫了一眼
读过第一部分，后面的模式部分相对目前的技术来说有所过时，属于经典重读系列中可以略过部分，当然有时间的话是可以读读原著。
2021年读，内容有点陈旧，未看完
对于企业应用开发有很大的指导意义，我们遇到的问题先辈们早已遇到过了，想要深入还是得继续看领域驱动设计
下载
收藏