NET中的企业架构设计.doc

设计的一个重要目标就是降低程序的复杂度，最明显的例子就是分层和工作流。从而是程序可理解，可控制。 架构关注构成应用程序的主要元素和组件的使用以及它们之间的交互。而设计则主要关注与数据结构和算法的选择，以及组件细节的实现。这些都是设计需要考虑的。架构和设计关注的东西通常重叠在一起，与其使用生硬或快速的原则来区分架构和设计，倒不如把这两方面结合在一起。有时候，决策在实质上更注重架构；而有时候，决策又更注重设计以及设计如何帮助我们实现架构。 在软件设计中，基本的做法是把软件分模块，分层（例如常见的3层架构）。专业的说就是把软件分为不同的关注点来尽量减少复杂度，模块的划分也会是程序分工明确，即所谓高内聚低耦合。 下面描述了设计的关键原则 关注点分离 单一职责原则 最少知识原则（也称为迪米特法则）。组件对象不应该了解其他组件的内部细节。 不重复自己（DRY） 尽量减少预先设计。只有必要时才去设计。某些情况下，当开发的成本或是设计失败的成本非常高的是，我们才需要预先进行全面的设计和测试。 横切关注点：诸如日志、异常处理等，横跨各个模块的功能。 如果已经在文档中记录候选架构和架构的测试用例，那么请确保文档足够轻量，这样您才可以很方便地对其更新。 依赖倒置原则：类之间依赖的应该是抽象，这样才能采用从上到下的方式进行设计，而并不需要先对底层模块进行设计。抽象不应该依赖于细节—细节应该依赖于抽象。 横切代码指的是有关安全、通信或运营管理（比如日志和指示器）的代码。 领域驱动设计：领域驱动设计可以在业务实体中封装业务规则。但是领域模型设计很难正确实现，并且往往关注某个视角或上下文。在下列情况下可以考虑在领域模型中封装规则：如果您的程序是富客户端或RIA，其中部分的业务逻辑部署在客户端而且业务模型实体在内存中初始化和持久化；或者您的领域模型可以通过和Web服务器关联的会话状态进行维护。 领域设计并不是总是比普通的实体设计更好，只有那些业务非常复杂，并且设计的是富客户端程序并且可以在内存中初始化和持久化适合。因为一方面领域模型比较难设计，需要对业务规则非常了解，另一方面领域模型会把数据和动作都封装在对象中，这对无状态的Web程序直觉上就不合适。 为了帮助维护模型语言的纯正性和可理解性，通常必须对领域模型进行大量的隔离和封装。因此，使用领域驱动设计构建的系统成本相对较高。不过领域驱动设计有着可维护性高等很多技术优势。如果您在设计时面对的是一个复杂的领域，那么可以考虑使用领域驱动设计，这种情况下，使用模型和语言一方面可以使沟通更加清晰。另一方面可以让团队对于领域的理解一致。 微软企业类库就是关注的就是横切面的东西，可以认为企业类库是面向方面编程的利器。 敏捷团队如何避免软件的腐化 不要过度设计。你当前的设计永远是针对我们能看到的需求（很短，也许是几周、几个月的需求），永远不要假设自己的前瞻性，因为需求是易变的。 我们拥抱需求变更，因为这就是软件开发的本质。因此在实现新需求的时候，团队一定要抓住这次机会去改进设计，以便设计对将来的同类变化具有弹性，而不是设法去打补丁。 正如前面所讲的，如果要避免设计腐败，就是永远要保持敏感性，使团队的每个人都对程序的整个结构保持清晰，哪种自上而下，官僚的任务分配会丢失对系统设计的控制权。从这一点讲要求项目经理、架构师具有一线编码能力，而且程序员也要必备的设计理念。 敏捷开发人员要随时应用设计原则去诊断问题。 他们应用适当的设计模式去解决问题。 敏捷开发人员致力于保持设计尽可能地适当、干净。这不是随便或者暂时性的承诺。敏捷开发人员不是每几周才清洁他们的设计。而是每天、每小时、甚至每分钟都要保持软件尽可能地干净、简单并富有表现力。他们从来不说，“稍后我们会回来修正它。”他们决不让腐化出现。 敏捷开发人员对待软件设计的态度和外科医生对待消毒的过程的态度是一样的。消毒过程使外科手术成为可能。没有它，被感染的风险之高是难以忍受的。敏捷开发人员对于他们的设计有同样的感觉。即使最小的腐化带来的风险也同样高到无法忍受。 设计必须保持干净、简单，并且由于源代码是设计最重要的表示，所以它同样要保持干净。职业特性要求我们，作为软件开发人员，不能忍受代码腐化。 重量级的方法以文档为驱动，重量级的设计，但是需求是易变的，因此在程序演变的过程中，文档会变得过时，同时设计也迅速变得不合时宜，腐败。因此，只有轻量的、敏捷的、反复迭代、经常交付的软件才会避免软件变得不合时宜和腐败。 下面是关于架构、模式的关系图 架构原则 架构模式 架构模式 架构模式 设计原则 设计模式 设计模式 设计模式 业务层的几种设计模式 过程式模式。在面向对象兴起之前，业务逻辑层不过是一系列过程的集合，每个过程都用来处理来自表现层的一个请求。 事物脚本。最直接的面向过程模式，这是最原