做网站有必要要源码吗,云计算公司排名,wordpress安装程序,如何做企业网站加v导读#xff1a;企业应用包括哪些#xff1f;它们又分别有哪些架构模式#xff1f;世界著名软件开发大师Martin Fowler给你答案
01、什么是企业应用 我的职业生涯专注于企业应用#xff0c;因此#xff0c;这里所谈及的模式也都是关于企业应用的。#xff08;企业应用还…导读企业应用包括哪些它们又分别有哪些架构模式世界著名软件开发大师Martin Fowler给你答案
01、什么是企业应用 我的职业生涯专注于企业应用因此这里所谈及的模式也都是关于企业应用的。企业应用还有一些其他的说法如“信息系统”或更早期的“数据处理”。那么这里的“企业应用”具体指的是什么呢我无法给出一个精确的定义但是我可以罗列一些个人的理解。
先举几个例子。企业应用包括工资单、患者记录、发货跟踪、成本分析、信用评分、保险、供应链、会计、客户服务以及外汇交易等。企业应用不包括汽车燃油喷射、文字处理、电梯控制、化工厂控制器、电话交换机、操作系统、编译器以及电子游戏等。
企业应用一般都涉及持久化数据。数据必须持久化是因为程序的多次运行都需要用到它们——实际上有些数据需要持久化若干年。在此期间操作这些数据的程序往往会有很多变化。这些数据的生命周期往往比最初生成它们的那些硬件、操作系统和编译器还要长。在此期间为了存储新的信息而不干扰旧的信息数据的结构经常会发生许多变化。即使是有根本性的变化发生或公司安装了一套全新的软件来处理某项任务这些数据也必须被“迁移”到新的应用上。
企业应用一般都涉及大量数据——一个中等规模的系统往往都包含1GB以上的数据这些数据是以数千万条记录的方式存在的。巨大的数据量导致数据的管理成为系统的主要工作。早期的系统使用的是索引文件结构如IBM的VSAM和ISAM。现代的系统往往采用数据库绝大多数是关系型数据库。设计和填充这些数据库已经成为一个独立的专业领域。
企业应用一般还涉及很多人并发访问数据。对于很多系统来说人数可能在100人以下但是对于一些通过互联网进行通信的基于Web的系统人数则会呈指数级增长。要确保这些人都能够正确地访问数据就一定会存在这样或那样的问题。即使人数没有那么多要确保两个人在同时操作同一数据项时不出现错误也是存在问题的。事务管理工具可以处理其中的一些负担但是它通常无法做到对应用开发者隐藏。
企业应用还涉及大量操作数据的用户界面屏幕。有几百个用户界面屏幕是不足为奇的。企业应用的用户从偶尔使用到定期使用都有他们也经常没什么技术背景。因此出于不同的使用目的数据需要很多种表现形式。系统一般都有很多批处理过程但当专注于强调用户交互的用例时这些批处理过程很容易被忽视。
企业应用很少独立存在通常需要与散布在企业周围的其他企业应用集成。这些各式各样的系统是在不同时期采用不同技术构建的甚至连协作机制都不同COBOL数据文件、CORBA系统或是消息系统。企业经常希望能用一种统一的通信技术来集成所有系统。当然每次这样的集成工作几乎都很难真正实现所以会有几个不同的统一集成方案同时存在。当业务组织需要同其业务伙伴进行应用集成时情况就更糟糕。
即使是某家公司统一了集成技术它们也还是会遇到业务流程中的差异以及数据中概念的不一致性。一个部门可能认为客户是当前签有协议的人而另外一个部门可能还要将那些以前有合同但现在已经没有了的人计算在内。再有一个部门可能只关心产品销售而不关心服务销售。粗看起来这些问题似乎容易解决但是一旦几百条记录中的每个字段都有可能存在着细微差别问题的规模就会形成不小的挑战——就算唯一知道这些字段真正含义的员工还在公司任职当然所有这些都会毫无预警地发生变化。这样数据就必须被不停地以各种不同的语法和语义格式读取、转换和写入。
再接下来的问题是由“业务逻辑”带来的。我认为“业务逻辑”这个词很滑稽因为很难再找出什么东西比“业务逻辑”更加没有逻辑。当我们构建一个操作系统时总是尽可能地使得系统中的各种事物符合逻辑。而业务规则是人家给你的没有相当的行政努力不要想改变它当然它们都有自己的理由。你必须面对很多奇怪的条件而且这些条件相互作用的方式也非常怪异。比如某个销售人员为了签下其客户几百万美元的一张单可能会在商务谈判中与对方达成协议将该项目的年度到账时间推迟两天因为这样才能够与该客户的账务周期相吻合。成千上万的这类“一次性特殊情况”最终导致了复杂的业务“无逻辑”使得商业软件开发那么困难。在这种情况下必须尽量将这些业务逻辑组织成有效的方式因为我们可以确定的是这些“逻辑”一定会随着时间不断变化。 ▲对不同的领域逻辑组织方式领域逻辑的复杂度和工作量之间的关系示意
对于一些人来说“企业应用”这个术语指的是大型系统。但是记住这一点很重要并不是所有的企业应用都是大型的尽管它们可能都为企业提供巨大的价值。很多人认为由于小型系统的规模不大所以不值得为之操心在某种程度上这是合理的。如果一个小型系统失败了它通常不会像大型系统那样引起广泛关注。但是我认为这种思想没有对小型项目的累积效应给予足够的重视。试想如果在小型项目上能够进行某些改善措施那么这种累积效应对企业的影响是非常显著的特别是因为小型项目通常具有不成比例的价值。实际上你可以做的最好的事情之一是通过简化架构和过程将一个大型项目变成小型项目。
02、企业应用的种类 在我们讨论如何设计企业应用以及使用哪些模式之前认识到这一点很重要企业应用是多种多样的不同的问题将导致不同的处理方法。如果有人说“总是这样做”的时候就应当敲响警钟了。我认为设计中最具挑战性也是我最感兴趣的地方就是了解有哪些候选的设计方案以及各种不同设计方案之间的优劣比较。进行选择的空间很大但我在这里只选三个方面。
考虑一个B2CBusiness to Customer的在线零售商人们浏览和——运气好还有购物车——购买。这样一个系统必须能够应付大量的用户因此其解决方案不但要考虑到资源利用的高效还要考虑到系统的可伸缩性以便在用户规模增大时能够通过增加硬件的办法加以解决。这样的应用的领域逻辑可能非常直接获取订单进行简单的价格计算和发货计算给出发货通知。我们希望任何人都能够轻松访问该系统因此用户界面可以选用通用的Web表现方式以支持各种不同的浏览器。数据源包括用来存放订单的数据库还可能包括某种与库存系统的通信交流以便获得商品的可用性信息和发货信息。
再考虑一个租约自动处理系统。在某些方面这样的系统比起前面介绍的B2C零售商系统要简单得多因为它的用户数很少在特定时间内不会超过100个但是它的业务逻辑却比较复杂。计算每个租约的月供处理诸如提早解约和逾期付款这样的事件签订合同时验证各种数据这些都是复杂的任务因为租约行业的许多竞争都是以过去的交易为基础稍加变化而出现的。正是因为规则的随意性很大才使得像这样一个复杂的业务领域具有挑战性。
这样的系统在用户界面UI上也更加复杂。这就要求HTML界面要能提供更丰富的功能和更复杂的屏幕而这些要求往往是HTML前端目前无法达到的需要更传统的富客户界面。用户交互的复杂性还会带来事务行为的复杂性签订租约可能要耗时12小时这期间用户要处于一个逻辑事务中。一个复杂的数据库设计方案中可能也会涉及200多个表以及一些有关资产评估和计价的软件包。
第三个例子是一家小型公司使用的简单的“开支跟踪系统”。这个系统的用户很少逻辑简单并且可以通过HTML表示轻松地在整个公司访问唯一的数据源是数据库中的几个表。尽管如此开发这样的系统也不是没有挑战。一方面你必须快速地开发出它另一方面你又必须为它以后可能的发展考虑也许以后会为它增加计算报销支票的功能也许它会被集成到工资系统中也许还要增加关于税务的功能也许要为公司的CFO生成汇总报表也许会被集成到一个航空订票Web Service中等等。如果在这个系统的开发中也试图使用前面两个例子中的一些架构可能会影响开发进度。如果一个系统会带来业务效益如所有的企业应用应该的那样则系统进度延误同样也是开销。你不希望现在做出的决策会阻碍未来的发展。但是如果现在就考虑了这些灵活性但是考虑不得当额外的复杂性又可能会让系统在未来变得更难演化进一步延误系统部署减少系统的效益。虽然这类系统很小但是一个企业中往往有很多这样的系统这些系统的架构不良性累积起来后果将会非常可怕。
这三个企业应用的例子都有难点而且难点各不相同。当然也不可能有一个适合于三者的通用架构。选择架构时必须很清楚地理解系统的特定问题在理解的基础上再来选择合适的设计。 03、企业架构模式 模式的概念早就有了。我在这里不想把这段历史重新演绎一遍。只是想简单谈谈我对模式和它们为什么是描述设计的重要手段的一些看法。
模式没有统一的定义可能最好的起点是Christopher Alexander给出的定义这也是许多模式狂热者的灵感来源
“每一个模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心。这样你就能一次又一次地使用该方案而不必做重复劳动”[Alexander et al.]。
尽管Alexander是建筑家他谈论的是建筑模式但其定义也能很好地适用于软件业。模式的核心就是特定的解决方案它有效而且有足够的通用性能解决重复出现的问题。模式的另一种视角是把它看成一组建议而创造模式的艺术则是将很多建议分解开来形成相互独立的组在此基础上可以相对独立地讨论它们。
模式的关键点是它们源于实践。必须观察人们的工作过程发现其中好的设计并找出“这些解决方案的核心”。这并不是一个简单的过程但是一旦发现了某个模式它将是非常有价值的。
一旦需要使用模式就必须知道如何将它运用于当前的问题。使用模式的关键之一是不能盲目使用这也是模式工具为什么都那么惨。我认为模式是一种“半生不熟品”为了用好它还必须在自己的项目中把剩下的那一半“火候”补上。我本人每次在使用模式时都会东改一点西改一点。因此你会多次看到同一个解决方案但没有一次是完全相同的。
每个模式相对独立但又不彼此孤立。有时候它们相互影响如影随形。
《企业应用架构模式》一书中总结出的51种模式 如果你是一个有经验的企业应用设计师也许会对大多数模式都很熟悉。模式不是什么新鲜概念。因此撰写模式书籍的作者也不会声称我们“发明”了某某模式而是说我们“发现”了某某模式。我们的职责是记录通用的解决方案找出其核心并把最终的模式记录下来。对于一个高级设计师模式的价值并不在于它给予你一些新东西而在于它能帮助你更好地交流。如果你和你的同事都明白什么是远程外观你就可以这样非常简捷地交流大量信息“这个类是一个远程外观模式。”也可以对新人说“用数据传输对象模式来解决这个问题。”模式为设计提供了一套词汇这也是模式的名字如此重要的原因。
当你使用模式时请记住它们只是开始而不是结束。任何作者去囊括项目开发中的所有变化和技术是不可能的。我编写《企业应用架构模式》一书的目的也只是作为一个开始希望它能够把我自己的和我所了解的经验和教训传递给读者你们可以在此基础上继续努力。请大家记住所有模式都是不完备的你们都有责任在自己的系统中完善它们你们也会在这个过程中得到乐趣。 关于作者
马丁·福勒Martin Fowler世界著名软件开发大师Thoughtworks首席科学家从事软件开发相关工作30余年是全球软件架构、敏捷开发、极限编程、设计模式等多个领域的领袖人物。此外他在面向对象分析与设计、UML、数据库、领域特定语言等领域也有深厚的积累和卓越的贡献。 本文摘编于《企业应用架构模式》书号9787111746959经出版方授权发布转载请标明文章出处。
