主要观点总结
本文介绍了业务逻辑层在软件架构中的重要性及其设计过程，包括与领域专家的合作、业务逻辑层的模式应用以及PetShop的业务逻辑层设计。
关键观点总结
关键观点1: 业务逻辑层是系统架构中体现核心价值的部分，关注业务规则的制定和业务流程的实现。
业务逻辑层的设计过程需要领域专家的参与，以确保对领域业务的分析与理解。
关键观点2: 与领域专家的合作是项目成败的关键，可以通过Innocent Questions模式改进领域专家和技术专家的沟通质量。
需要确保团队中至少有一名领域专家，明确其角色任务与职责，包括制定业务规则和流程、与客户沟通、需求调研与讨论以及与设计师共同参与系统架构。
关键观点3: 业务逻辑层的模式应用包括事务脚本模式、领域模型模式和表模块模式。
PetShop的业务逻辑层设计中引入了领域模型模式，通过对购物车（Cart）类的设计体现了这一点。
关键观点4: PetShop的业务逻辑层设计相对简单，主要因为省略了复杂的业务逻辑细节。
在业务逻辑层中定义了相关的领域对象，如Cart类，但仅是对数据访问层的简单封装。
正文
传统的软件开发模型同样重视与领域专家的合作，但这种合作主要集中在需求分析阶段。例如瀑布模型，就非常强调早期计划与需求调研。然而这种未雨绸缪的早期计划方式，对架构师与需求调研人员的技能要求非常高，它强调需求文档的精确性。一旦分析出现偏差，或者需求发生变更，在项目开发进入设计阶段后，由于缺乏与领域专家沟通与合作的机制，开发人员估量不到这些错误与误差，因而难以及时做出修正。一旦这些问题像毒瘤一般在系统中蔓延，逐渐暴露在开发人员面前时，已经成了一座难以逾越的高山。我们需要消耗更多的人力、物力，才能够修正这些错误，从而导致开发成本成数量级地增加，甚至于导致项目延期。当然还有一个选择，就是放弃整个项目。这样的例子不胜枚举，事实上，项目开发遭遇“滑铁卢”，究其原因，大部分都是因为业务逻辑分析出现了问题。
迭代式模型较之瀑布模型有很大的改进，因为它允许变更以优化系统需求。整个迭代过程实际上就是与领域专家的合作过程，通过向客户演示迭代产生的系统功能，及时获取反馈，并逐一解决迭代演示中出现的问题，保证系统向着合乎客户需求的方向演化。因而，迭代式模型往往能够解决早期计划不足的问题，它允许在发现缺陷以及需求变更时重新设计，重新编码并重新测试。
无论采用何种开发模型，与领域专家的合作都将成为项目成败与否的关键。这基于一个软件开发的普遍真理，那就是世界上没有不变的需求。一句经典名言是：“没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。”一语道尽了软件开发的残酷与艰辛！
那么应该如何加强与领域专家的合作呢？James Carey和Brent Carlson根据他们在参与的IBM SanFrancisco项目中获得的经验，提出了Innocent Questions模式，其意义即“改进领域专家和技术专家的沟通质量”。在一个项目团队中，如果我们没有一位既能担任首席架构师，同时又是领域专家的人选，那么加强领域专家与技术专家的合作就显得尤为重要了。毕竟，作为一个领域专家而言，可能并不熟悉软件设计方法学，也不具备面向对象开发和架构的能力。同样，大部分技术专家很有可能对该项目所涉及的业务领域仅停留在一知半解的地步。如果领域专家与技术专家不能有效沟通，整个项目的前途就岌岌可危了。
Innocent Questions模式提出的解决方案包括：
-
选用可以与人和谐相处的人员组建开发团队；
-
清楚地定义角色和职权；
-
明确定义需要的交互点；
-
保持团队紧密；
-
事实上，这已经从技术的角度上升到对团队的管理层次了。就好比篮球运动一样，即使你的球队集合了5名世界上最顶尖最有天赋的球员；如果没有整体的配合，各自为战，要想取得比赛的胜利依旧是非常困难的。团队精神与权责分明才是取得胜利的保障，软件开发同样如此。
