引言
P3 “业务逻辑”无逻辑
原文
我认为“业务逻辑”这个词很滑稽，因为很难再再找出什么东西比“业务逻辑”更加没有逻辑。
成千上万的这类“一次性特殊情况”最终导致了 复杂的业务“无逻辑” 使得商业软件开发那么困难。在这种情况下，必须尽量将这些业务逻辑组织成有效的方式，因为我们可以确定的是，这些“逻辑”一定会随着时间不断变化。
笔记
太对了，业务逻辑千奇百怪。
P14 跨层次调用在实践过程中往往运行良好
原文
有时，层次组织成领域层对表现层完全隐藏了数据源层。但更多的时候，是表现层直接对数据存储进行操作。虽然这样做并不纯粹，但是在实践中往往运行良好。表现层可能解释来自用户的命令，通过数据源层将相关数据从数据库中提取出来，然后让领域逻辑层在向用户显示相关数据之前先处理这些相关数据。
笔记
合理的灵活使用，不要死板
P15 下层绝对不要依赖表现层
原文
一条关于依赖性的普遍原则：领域层和数据源层绝对不要依赖于表现层。
P15 区分领域逻辑&不要教条
原文
使用领域逻辑时，其中一个最困难的部分就是区分什么是领域逻辑，什么是其他逻辑。一种不太正规的测试办法就是：假想向系统中增加一个完全不同的新层，例如为Web应用增加一个命令行界面层。如果在这个过程中，发现需要重复实现某些功能，则说明可能有一些本应该在领域层实现的逻辑，现在在表现层实现了。类似的，你也可假想一下，将后台数据库更换成XML文件格式，看看情况又会如何？
举一个例子。我所知道的一个系统有一张产品列表，其中，当月销量比上月销量大10%的产品需要用红色显示。为实现这个功能，开发者在表现层逻辑中比较当月和上月的销量，然后将差别大于10%的产品显示为红色。
这样做的麻烦就是将领域逻辑放到了表现层中。为了进行适当的分离，需要在领域层中定义一个方法，用来指示该产品的销量是否较上月有较大提高。该方法完成销售量的比较，返回一个布尔值。表现层则只需要简单地调用一下这个布尔方法，如果返回值为真，则用红色突出显示这个产品。这样，该过程就分解成两部分：确定需不需要突出显示，选择如何突出显示。
当然，我担心这样也许有些太教条主义了。Alan Knight在审阅本书评论说：他自己“很头大，将部分领域逻辑混入表现层到底是滑向地狱的第一步呢，还是只有少数纯粹主义者才会抱怨的小问题？”我们之所以担心，正式因为这两种做法两者兼备。
P17 尽可能所有代码保持在单一进程
原文
尽可能所有代码保持在单一进程内完成（可能是在同一节点上，也可能拷贝在集群中的多个节点上）。除非不得已，否则不要把层次放在多个进程中完成。因为那样做不但损失性能，而且增加复杂性，因为必须增加类似下面的模式，如远程外观和数据传输对象。
P23 服务层
原文
处理领域逻辑的场景方法是将领域层再细分成两层。服务层独立出来，置于底层的领域模型或表模块之上。通常只有使用领域模型或表模型时才会这样细分，因为仅使用事务脚本的领域层并不复杂，没有必要再单独设置服务层。表现逻辑与领域层的交互完全通过服务层，就好像应用程序的API一样。
在提供一个清晰的API的同时，服务层也是放置事务控制和安全功能的好场所。
P27 领域模型和数据库完全独立
原文
领域模型和数据库完全独立，可以让间接层完成领域对象和数据库表之间的映射。这个数据映射器处理数据库和领域模型之间所有的存取操作，并且允许双方都能独立变化。这是数据库映射架构中最复杂的架构，但它的好处是把两个层完全独立了。
850
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
