亚

在领域模型模式中，我们大都是将服务层看作是业务层的一部分。虽然这个做法非常常见，不过显然，我们还有其他选择。通常来说，服务层为表现层定义了一个接口，从而允许表现层触发一些预定义的系统操作。正如名称表现出来那样，服务层可以看作是表现层结束、业务逻辑层开始的一个边界，服务层用来尽可能的降低表现层和业务逻辑层之间的耦合，让表现层无需关注业务逻辑层中的具体实现组织方式。因此，无论你选择任何一种业务逻辑模式

综述 如果没有用户界面，哪个程序都不能运行。哪怕是中间层代码堪称完美，用户也无法使用到。很多架构师不太重视表现层，仅将表现层作为业务层和数据访问层完成后的一个细节处理。但实际上，用户界面、业务逻辑和数据访问代码在任何一个系统中都是同等重要的。你的态度、偏好和自身的专业技能决定了你为每个层制定的“优先级”，也导致了你对各个层的关注顺序。 实际的开发中，表现层经常是系统中最后开发的一部分，且非常依赖于

业务层剖析 任何复杂的任何软件都可以通过层来组织，每一层表示系统中的一个逻辑部分，一般来说，业务逻辑层中的模块包含了系统所需要的所有功能上的算法和计算过程，并于数据层和表现层交互。抽象的说，业务逻辑层是软件中专门处理业务相关任务性能的部分。 业务逻辑层表示了系统的逻辑，此处的代码将要进行必要的决断并执行操作。前面谈到过安全性，在业务逻辑层的安全性意味着使用基于角色的安全原则，仅允许认证用户访问特定

这篇博客之所讲UML出现在了《Microsoft.Net企业级应用架构设计》一书的第二章，从架构上讲不应该出现这节知识点，但是从架构师的职责角度，UML知识点是一个基础，因此作者独立出了一个章节。大家在学生时代都有学习和接触过UML，那就当作是对于UML的复习了。 若想设计一个系统，无论是任何领域的任何系统，都需要首先对其抽象，抽象就是指建立一个模型，对系统视图、结构、行为、参与的实体和流程方面提

综述 数据访问层的设计很大程度上取决于项目干系人需求的影响。例如，数据访问层应该持久化对象模型还是简单的的值的集合？数据访问层应该支持一种数据库还是多种数据库？下面仔细分析数据访问层的常见功能需求。 数据库独立性：数据访问层是系统中唯一知道并使用连接字符串和数据表名称的地方，考虑到这些，数据访问层必须要依赖于数据库管理系统DBMS，对于外部观察者，数据访问层应该就像一个黑盒，可以插入到现有系统中，

前段时间刚刚看完了《Microsoft .Net企业级应用架构设计》一书，以后陆续的分享作者在书中的精华，简明扼要的进行总结和概述。同时这本书推荐给有兴趣的童鞋。软件架构到底是什么 每次遇到软件项目时，我们都会创建一个解决方案。这个过程就叫做架构设计，而架构设计的最终产物就是软件架构。在软件领域，架构就是指为客户构建系统。 软件架构分为隐式和显式两种。隐式架构可以看作是一系列原有经验，其他类似项目

基本设计原则 写出可以正常工作的代码是一回事，写出可以正常工作的良好代码则是另外一回事。一个设计精良的系统并不是一系列指令和修补的堆砌，里面还有很多与设计直接或间接相关的东西。与国际化标准中定义的其他质量特性相比，需要更加重视代码的可维护性，之所以选择这个特性，并不是因为其他特性（例如可扩展性、可伸缩性）和可维护性相比不重要，而是保持代码的可维护性的代价比较高，而且容易让开发者忽视，可维护是系统最