读后感：

Martin Fowler 20年前的书，OO和领域的思想对于今天的我们来说很基础，但在那时应该算是萌芽。Smalltalk语言简单，语法中省略空格可能因为那时的硬件设备昂贵，而不得不做出的选择，但是可读性真的很差，而书中基本是用Smalltalk进行示例。翻开这本书是为了查找财务模型，它没有让我失望，特别是第6章“库存与财务”给了我思维建模的概念。这本书和UML、GOF的“设计模式”差不多是在同一时间段出现，所以书的内容看上去有点古董的感觉。不过，大师的思路有时候都是接近的。这本书还让我联想到，其实软件开发领域这几十年并没有改变多少，对比更新迭代很快的手机来说，我们算是很幸运的了。

读书笔记：

第1章 绪论

建模原则：概念模型是与接口（类型）而不是与实现（类）相关联的。

建模原则：模式是起点，而不是终点。

建模原则：模型无好坏对错之分，只有有用还是无用之分。

作者的电子邮件（邮件地址是100031.3311@compuserve.com）

第3章 观察和测量模式

关键概念：数量、单位、测量、观察、观察概念、现象类型、关联函数、被否决的观察、假设

建模原则：当多个属性与可能会在几个类型中使用的行为相关时，就把这些属性组合成新的基础类型。

建模原则：操作级中的对象会经常发生变化。它们的配置由很少发生变化的知识级来约束。

建模原则：如果某个类型拥有多种相似的关联，可以为这些关联对象定义一个新的类型，并建立一个知识级类型来区分它们。

第4章 针对公司财务的观察模式

关键概念：企业片断、维度、测量方案、状态类型

第6章 库存与财务

关键概念：账目、事务、条目、记入规则

建模原则：要记录一个值的变更历史，可以为这个值设立一个账目。

事务明确地把取款条目和存款条目联系起来。双条目法反映一个基本的账务原理。

建模原则：在使用账目时要遵守守恒原理：需要清算的物品不能凭空生成和消失，它仅仅是从一个地方转移到另一个地方。这使得发现和防止不守恒变得容易。

可逆性：记入规则的一个重要属性就是它们必定是可逆的。通常我们不能删除一个错误的条目，因为它要么是支付的一部分，要么出现在账目清单上。我们清除它的作用的惟一方法就是输入一个同样的但是相反的条目。

建模原则：为了确认计算是如何进行的，把计算的结果表示成对象，由它来记住是由哪个计算产生的结果以及计算所使用的输入值是什么。

 图释：如果使用多重汇总账目，有可能会定义一个具有重叠细目账目的汇总账目。集合元素不允许重复。

如果觉得真的是个问题，我们就要在组合关系上加以限制，这个限制不允许我们选择带有重复的子账目。 

伊利诺伊大学厄巴纳-尚佩恩分校的研究人员已经在开发账务框架方面做了大量工作。

第12章 信息系统的分层构架

我们看到会存在这样的情况：GUI开发者理解用户界面环境但是根本不需要了解领域模型，而外观开发者理解领域模型但是不需要知道GUI开发。表示层/应用逻辑层的分离把需要的不同技术分割开来，从而使开发者为了做出贡献只需要学习较少的东 我们看到会存在这样的情况：GUI开发者理解用户界面环境但是根本不需要了解领域模型，而外观开发者理解领域模型但是不需要知道GUI开发。表示层/应用逻辑层的分离把需要的不同技术分割开来，从而使开发者为了做出贡献只需要学习较少的东西。

这个分离允许从一个单独的外观开发出多种表示。

外观为测试提供一个很好的平台。当外观和表示层被合并时，基础的计算只能够通过GUI进行测试，这需要手工测试（或者针对回归测试的GUI测试软件）。当这些被分隔开时，就能够为外观的接口编写一个测试程序。这样一来，只有表示层代码需要使用比较笨拙的工具来测试。

这个过程会发生一个例外，就是应用需要一个特殊的数据配置发生作用，并且在开始时只用一个步骤就能够从数据库中获得该数据，以便改善性能。在这种情况下，一个有用的做法是领域层提供针对具体应用的装载请求，这种请求给应用一个机会让领域层知道它想要请求什么。在某种程度上，这损害了领域层不应当知道什么应用使用它的原则，但是在一些环境中性能的改善是强制的。

一个解决方法是增加另一个层次——数据库接口层，它负责从数据库中为领域层装载数据和当领域改变时更新数据库。这个层也负责处理输入以及其它遗留交互。