本文针对《MS .NET企业级应用架构设计》业务层前半部分做了相关笔记并记录了自己的一点想法。对于后半部分的具体模式将在第二次笔记中体现。
关于Layer与Tier
Layer一般用来组织代码。例如当提到表现层(Presebtation Layer)，我们指的是应用程序前端的功能，而并不是某种客户端平台或技术。
Tier指代码运行的位置。Tier常指物理上的层次或一个物理层。或者可以这样说，Tier就是架构师让逻辑层运行的地方。
以前一直以为业务层只能应用在具体的某一物理层上，事实上，物理层的Tier与组织代码的Layer是有区分的，跨物理层的Layer只要适当在Layer混合层(Tier独立层)的代码中加以分离，仍然是可以达到良好的代码维护效果的。但个人感觉这并非推荐的模式。
关于是否推荐多物理层架构
物理层中一个层就表示一个需要穿过的边界，这个边界可能是进程的便捷也可能是计算机的边界。穿越边界的代价较高，一个估算比例是穿越便捷要比进程内部调用慢100倍左右。若需要通过网络访问，还要更慢一些。多物理层会导致整体性能的降低。
而有时又不得不需要多物理层。一个理由是需要支持外部产品，而外部产品需要自己的进程来运行；另一个理由是出于安全方面的考虑，运行于一个独立进程中的模块将会更容易被保护和访问。再者，多物理层架构具有可伸缩的特性，系统的组件可拆分至其他层并重复部署。
总之物理层的分层需要在系统性能与安全性、可伸缩性、容错性之间平衡。
在项目中遇到此类问题时，可将系统性能等综合考虑。在经历项目的同时发现，在同流程下，既有跨物理层通讯也有同物理层通讯的代码处理相当麻烦，两种形态的代码带来的可维护性极差，是否能够运用设计模式解决这一问题？
关于过程模式与对象模式
在业务层中，对其实现模式进行分解，可以分为过程模式与对象模式。
业务逻辑层被看作一系列相关的操作，系统需要执行的步骤被分割为更小的步骤，每一个步骤都用一个操作表示，这样的操作叫事务。在这个上下文中，事务是一个不可分割的逻辑操作，这个模式叫做事务脚本(Transaction Script) 。
另一种过程模式称之为表模块(Table Module)。表模块的设计角度仍是一系列事务，不过事务是按照数据分组的。操作被定义在表示表数据的对象上。我们使用表数据作为实体，组织方法。
对于对象模式，我们用一系列相互交互的对象来组织逻辑。最简单的对象模型看上去像是数据库表的数据模型，这里组成模型的对象就是数据库中的记录，并增加了一些额外的方法。这个模式叫做活动记录(Active Record)。抽象程度越高，与数据模型的距离也越大，这种高度抽象的模式叫做领域模型(Domain Model)。
从上图中可得出结论，对于复杂度较低的逻辑，采用过程模式能够产生较好的实现，但随着逻辑复杂度的提升，程序的代价将变得很高。原因在于过程模式的编码虽然简单高效，但需要不断的重构以减小“意大利面代码”带来的危害，而对于大多数程序员来说，一旦代码逻辑结果实现，一定会对其置之不理，因此由领域驱动的面向对象的业务层代码便体现出相当大的优势。对于复杂逻辑的代码可维护性与拓展性均比过程模式强健。
在具体的项目中，普通的过程性逻辑是适用过程模式的，也是我最熟悉的，尤其是事务脚本；但对象模式却经历的较少，今后可在组炉等复杂逻辑中考虑是否可以改成对象模式，加上设计模式的合理应用，应该会对程序的可维护性与可扩展性有较大幅度的提升。