精华内容
下载资源
问答
  • 企业级业务架构设计方法论.pdf
  • 理论性较强的架构体系总给人一种术高莫用之感,付晓岩老师的《企业级业务架构设计:方法论与实践》将Togaf之中的阶段B业务架构显化,详细说明了如何使用价值链进行业务架构设计。 其章节共分为四部分:第一部分介绍...

    导读:

     数字化转型的必经之路是架构设计,企业级架构设计方法论中Togaf首屈一指。理论性较强的架构体系总给人一种术高莫用之感,付晓岩老师的《企业级业务架构设计:方法论与实践》将Togaf之中的阶段B业务架构显化,详细说明了如何使用价值链进行业务架构设计。

    其章节共分为四部分:第一部分介绍了企业架构及业务架构、第二部分以价值链为核心讲解业务架构如何设计、第三部分讲解业务架构的持续落地、第四部分简单描述业务架构与中台关系。

    现将韩老师个人解读的读书笔记公布于此,与各位看官分享。

     

     

    图片

     

     

     

    01

     

     

    Togaf业务架构

     

     

    在执行企业架构过程中,将会产生大量输出,如业务流程、架构需求、项目计划、项目合规评估等。

     

    为了能以一致的、结构化的方式来校对和展示工作产出物,需要一个架构模型框架来放置这些工作产出物。

     

    这样方便工作产品的引用和标准分类,帮助改善不同结构的工作产出物之间的关系。

     

    Togaf内容原模型阐述了构建快如何被描述和构建快间如何关联。

     

    图片

     

    其中业务架构包括:动机、组织、功能。业务架构需要预备阶段制定的架构原则、架构愿景阶段的业务战略、业务原则、架构愿景等。

    其中战略是付晓岩老师在业务架构设计中一直强调的基础。


    架构工作同开发一样,也需要交付。在Togaf定义中架构会输出制品、交付物等。其中Togaf业务架构输出的制品包括:目录、矩阵、图。

     

    目录包括:组织/执行者目录、角色目录、流程/事件/控制/产品目录等。

    矩阵包括:业务/交互矩阵、执行者/角色矩阵。

     

    图形包括:业务足迹图、业务服务图、功能分解图、用例图、组织分解图、流程图、事件图等。

     

    Togaf业务架构交付物包括:风险管理、架构定义文档、架构需求规格说明书、业务场景、差距分析、架构构建快、解决方案构建快等。

     

    图片

    其交付物与付晓岩老师此书第三部分相吻合。

     

    Togaf一直强调是基于能力的业务规划,其方式之一是使用价值链完成业务分析工作,与付晓岩老师此书第二部分不谋而合。


     

     

    图片

     

     

    02

     

     

    企业级业务架构设计:方法论与实践

     

     

    企业架构EA的理论框架总给人高高在上,术高莫用之感。


    这一方面是因为,企业架构本身是一个高阶软件研发课题,能够真正有机会参与到企业架构设计的人并不多;

     

    另一方面是因为,企业架构某些方面来讲偏形而上,从几套业界的方法论,到具体实践层面,存在着一个鸿沟,很多人可以泛泛的谈论这套鸿沟上的桥梁的模糊形状,但具体如何搭建这座桥梁,其实并不清楚。

     

    整本书的核心,是通过价值链模型作为理论基础,基于价值链塑造的业务流程为出发点,分析多场景下的业务对象本质,并经过超越了业务场景的实体抽象过程,得到企业级视角下的数据模型。

     

    图片

     

    Togaf业务架构定义:

    所谓业务架构,是把企业的业务战略转化为日常运作的渠道,业务战略决定业务架构,它包括业务的运营模式、流程体系、组织结构、地域分布等内容。

     

    付晓岩:

    业务架构从企业战略出发,按照企业战略设计业务及业务过程,业务过程是需要业务能力支撑的,从战略到业务再到对业务能力的需要,就形成了支持企业战略实现的能力布局,可以将这个布局理解为业务架构,它是企业为客户创造价值的设计过程。

     

    图片

     

    业务架构设计完成后,“灵魂”就诞生了,IT架构则是根据“灵魂”的需要来设计“容器”。

     

    图片

     

    我们会看到战略设计变革组织设计,组织设计影响战略设计,业务分析推导组件设计,组件设计优化业务分析。战略与组织设计约束业务架构设计,业务架构设计实现战略与组织设计。

     

    作者在书中提到业务架构设计含两条线:行线与知线。

     

    图片

     

    不少技术人员不重视企业战略,认为企业战略与技术无关,这种想法大错特错。

     

    如果一个企业的战略使得员工觉得与自己无关,那么只能说明这个战略本身以及对战略的宣导是失败的。

     

    不落到流程中的战略是无法被执行的,而与战略落地无关的流程又是在干什么呢?创造的什么价值呢?为这样的流程开发的系统又是干什么呢?

     

     

    图片

     

    这震耳发聩的提问也反映出了现实的问题,在韩老师从业的过程中也发现同样的问题:业务人员、技术人员,甚至是管理人员对战略的忽视,这也严重制约了企业的数字化转型。

    有句话叫:未来以来,你爱来不来。

    数字化转型的今天如果还抱有原始软件思路,必定要被淘汰。

     

    图片

     

     

    迈克波特价值链模型:在波特的价值链模型中,认为企业在创造价值的过程中,所有生产经营涉及的活动可以分为两类,即支持性活动和基本活动,前者支撑价值创造过程,后者完整价值创造和增值过程。

     

    此价值链模型是付晓岩老师此书的核心方法论。


     

     

     

    价值链代表了构建企业能力统一视图的“横向”结构,每个价值链环节中均包含了若干个业务流程;业务领域代表了构建企业能力统一视图的“纵向”结构,描述了各类业务流程应如何通过组合实现领域级的业务目标。

     

    业务流程即业务活动,业务活动是由不同角色分别完成的若干任务组成的,任务执行过程中其必然与业务数据发生联系。数据主题域可以将关系紧密的数据进行聚类,再将与数据关系紧密的行为(也就是任务聚类),形成包含行为和数据的业务组件,组件代表了企业的某一类业务能力。

     

    图片

     

    利用5w1h分析法进行业务分析。

    通过When,Who,Where,Why,How,What来做分析,分析到底为什么要干这件事,这件事到底有没有价值?其实有时候我们判断价值的时候,用一个简单粗暴的方式去判断的话,就是你产生一个新活动,产生一个新任务了,有没有产生新数据,如果没有产生数据的话,那这个任务本身它的价值就没有那么高了。

     

    图片

     

    单从一个领域去分析,并看不出优势,当把两个、三个领域领域叠加起来,那么就可以抽象出公共能力、公共数据,就会形成整个业务视角,从价值创造过程到每个领域的具体活动任务。

     

     

    标准化最重要的是数据标准化。企业级数据模型要保证数据实体和属性的唯一性,这样就不会产生重复的概念,重复的概念会造成“同义不同名”,影响数据的使用和统计结果。

     

    任务标准化需要将流程模型与数据模型进行语义对接,分析重复的业务动作,做出标准化的建模判断。

     

    业务上重新审视、理清业务流程,搞清楚具体差异;数据上重新检视实体划分的颗粒度是否正确,避免过度设计。

     

    对于大型复杂的系统而言,需要践行标准化并持续建设,形成一张标准的企业能力地图。

     

    图片

     

    图片

     

    如果架构设计人员缺位,业务部门和项目团队沟通的结果可能会和最初建模存在差异,久而久之积累出很多“地方语言”,业务架构只能“自说自话”。

     

    一方面培养合格的业务架构师队伍,作为业务模型的“嘴”,另外是加强项目外的宣讲,用业务模型去解释业务。

     

     

    不惜血本去做企业级开发,其实最重要的是转变企业文化,打破部门壁垒,让企业融为一体。这种一体化带来的内部变化、清晰分工和高效协作才是最具价值的,是未来长期竞争力的关键,也是打造“数字化”企业的基础。


    做企业级难点不在于技术,企业级真正解决的问题是业务问题、组织问题、思想问题,是超越技术之上建立一个什么样企业的问题。

     

    时间也是架构师的“盟友”,架构师不能指望一次性说服所有人,只能像“盗梦空间”一样,先在对方头脑中“植入”一个“想法”,再逐渐引导“想法”生长。

     

    图片

     

    上述架构设计方法虽然也有基于流程和数据的标准化形成的组件和功能,但其对复用的表达依然偏重流程视角,是活动、任务的复用,而IT希望看到的,更直接的复用。

     

    业务架构师的首要责任定义为:“促进业务与技术的深度融合”。

     

    架构落地本质是一个沟通协调的过程。

     

    图片

     

    虽然架构设计二十多年的历史中不愠不火,但在阿里集团内部发展的很好,证明了业务架构设计有助于建立中台规划。

     

    企业级业务架构设计方法并非“银弹”,更不能简单照搬其他企业的架构套在自己身上。它更像一面镜子,镜子中照出的只能是你自己,而照镜子的过程也是一个“赋能”过程,赋予你认清自己的能力,达到“自知者明”的状态。

     

    图片

     

    一个普通士兵想要变成一个特种兵,不是因为给了他一身价值高昂的装备,而是经过了地狱般的训练。上至管理者,下至普通员工,若人的思维不发生转变,则不会带来企业的转变。

     

    软件行业没有“银弹”,任何方法都需要长期坚持并灵活运用,企业级架构是不断演进和迭代的。

     

    图片

    展开全文
  • 付晓岩-企业级业务架构设计方法论-IAS2019演讲.pdf
  • 企业级业务架构的诞生;能力的沉淀标准化;设计的一般过程;架构落地本质上是一个沟通协调的过程;落地之后形成真正的企业能力视图;困难重重物有所值吗;阿里巴巴为什么能够诞生一个中台;架构演进方向实现更好的内外部...
  • 企业级业务架构 EBA 设计方法论 付晓岩 到底有什么问题要靠它来解决 砸烟囱 数字化 双模开发 复用 提高企业的整体性 减低成本 企业转型 为什么能提高企业的整体性 战略 解析 整体规划 传导 指导 企业级 IT实现 业务...
  • 随着《企业级业务架构设计:方法论与实践》一书的传播,笔者有了更多的机会与来自不同行业的读者共同讨论业务架构这个话题,业务架构与“中台”的关系也时常会被读者问起,笔者就以这篇短文,将与大家交流的情况做个...
  • 企业级业务架构

    千次阅读 2020-06-24 09:34:38
    业务架构是以实现企业战略为目标,构建企业整体业务能力规划并将其传导给技术实现端的结构化企业能力分析方法。 业务架构的意义: 业务架构是以实现企业战略为目标,构建企业整体业务能力规划并将其传导给...
    • 业务架构的定义:

             业务架构是以实现企业战略为目标,构建企业整体业务能力规划并将其传导给技术实现端的结构化企业能力分析方法。

    • 业务架构的意义:

             1 业务架构是连接业务与IT的纽带,用于实现业务需求到IT的顺利传导,对于企业架构理论来说,业务架构也承担着将企业战略落地的职责。在通向“数字化”时代的进程中,业务架构的独特性在于帮助企业完成了深刻的“数字化”转型,使企业通过信息技术将内部、业务与IT深刻地连接起来,成为高效的“数字化”企业。

              2 业务架构可以帮助业务人员整体化、结构化地思考问题,从业务和系统的整体视角,附带一些对技术的基础了解,如分层理念、服务化、微服务化等,去理解业务和技术;同时还能够帮助技术人员理解、归纳业务人员的想法和目标,从而让业务和技术能够处于同一个语境之下,使用同一种“语言”工作。

    •  

      企业级架构事件案列   

              中国建设银行“新一代”核心系统建设,采用了企业级建模方法,形成了以“四个一(一套模型、一套IT架构、一套实施工艺和一套管理流程)”为特征的企业级工程实施方法,全面建立集团层面的流程模型、数据模型、产品模型和用户体验模型;
              中国工商银行整合构建企业级业务架构,“重构了适应新时期发展需要的业务架构视图,重新规划整合了28个领域的业务架构,形成了2300余个任务组件”,“通过强化业务架构的顶层设计和跨条线的协同联动,为后续进一步打造更具新时代基因的智慧金融体系奠定基础”。

     

    展开全文
  • Microsoft+.NET企业级应用架构设计

    热门讨论 2012-02-20 17:54:59
    《Microsoft .NET企业级应用架构设计》由两位企业级系统开发专家执笔,会告诉你如何用各种模式和技术来控制项目的复杂性,让系统更易于编写、维护和升级。  读者会得到实用的架构方面的指导,包括:  ·在早期设计...
  • 业务层剖析 任何复杂的任何软件都可以通过层来组织,每一层表示系统中的一个逻辑部分,一般来说,业务逻辑层中的模块包含了系统所需要的所有功能上的算法和计算过程,并于数据层和表现层交互。抽象的说,业务逻辑层...

    业务层剖析

    任何复杂的任何软件都可以通过层来组织,每一层表示系统中的一个逻辑部分,一般来说,业务逻辑层中的模块包含了系统所需要的所有功能上的算法和计算过程,并于数据层和表现层交互。抽象的说,业务逻辑层是软件中专门处理业务相关任务性能的部分。

    业务逻辑层表示了系统的逻辑,此处的代码将要进行必要的决断并执行操作。前面谈到过安全性,在业务逻辑层的安全性意味着使用基于角色的安全原则,仅允许认证用户访问特定的业务对象。从外界看,业务逻辑层可以看作是一个操作业务对象的机制,一般来说,业务对象不过是某个领域实体的实现,或者是某类辅助类型,用来执行一些计算。业务逻辑层处于分层系统的中间位置,业务逻辑层的输入和输出不一定是业务对象,很多时候,架构师更倾向于使用数据迁移对象在层之间交换数据。

    数据迁移对象和业务对象之间的取舍一直是团队中争议的话题。建议使用数据迁移对象的理论认为,数据迁移对象能减少层之间的耦合,使系统更加整洁干净。不过在现实中,人们都会说复杂性已经很高,因此应该避免增加任何不必要的对象。一条实用的原则是,当已经有了数百个业务对象时,或许并不应该仅仅为了设计的干净而让这个数字加倍,在这种情况下,数据迁移对象通常就是业务对象。业务对象同时包含了数据和行为,是一个可以参与到领域逻辑的完整对象。而数据迁移对象更像是一种值,即一系列数据的容器而没有相关的行为。为了序列化,业务对象中的数据会复制到数据迁移对象中。除了get/set访问器之外,数据迁移对象没有逻辑行为。数据迁移对象并不仅仅是领域对象去掉了行为,它表示了特定领域对象的一个子集,用于专门的上下文中。一般来说领域对象是一个对象图,而数据迁移对象仅仅是所需要部分数据的投影而已。

    每个真实的世界组织都是基于一系列业务规则运行的。或许很多人没有认识到组织中存在的这些规则,但不能否认这些规则的存在。每个组织都有自己要实现的战略,而业务规则是保证实现这些战略的主要手段。战略决定了组织的发展方向,而业务给出了实现战略的具体做法。

    业务对象的属性来自于其映射的实体的属性,业务对象的方法来自于其自身的职责以及应用到该实体上的部分业务规则。业务规则在很多程度上是对数据的验证。换句话说,很多业务规则说到底就是验证某个业务对象的当前内容。按照这样的理解,若有专门的验证层,并让业务对象可选择的支持,这个设计将会非常不错。

    业务逻辑层不应该看作是一个整体的组件,或者一些不相关模块的组合。多年的实际经验告诉我们,业务逻辑层在其他层(经典三层)中适当的重复是可以接受的,也是很多程序的做法。不过这种做法有一定的限度,且不应该受到鼓励。

    业务层和其他层

    假设我们有一个经典的分层系统,分为表现层、业务层和数据访问层,那么业务逻辑分布在各个层中的百分比应该是多少?最权威的答案是0 - 100 - 0 。这个数字显然不现实,通常你应该尝试把所有的事情放在业务逻辑层完成,除了CRDU操作以及用户界面的调整。分散在表现层和数据访问层中的逻辑有可能只是处于性能方面的考虑才进行的重复。这些重复由一些系统总体功能的灰色地带导致,有时候我们都不知道该把他们放在何处,下面介绍几个常见的灰色地带。

    1、数据格式化。若在客户端进行可视化,那么表现层必须了解很多上下文以及系统的逻辑。若将格式化放在业务逻辑层,那么业务逻辑层就必须提供合适的方法,供客户端调用并获取可以直接显示的字符串。我们会有几个选择,第一是存放两个数据,原始数据和格式化之后的数据。第二是存放原始数据,需要时格式化。第三是按照输入时的格式直接存放。我们当然会选择第二种。

    2、CRUD操作。数据访问层应该仅仅用来处理数据库相关的操作,而业务逻辑判断又必须调用数据。

    3、存储过程。原因类同与CRUD访问。在涉及到数据库流量的问题时,基本可以通过添加硬件或更换更好的硬件来解决,此外,在业务逻辑层中可以进行适当的缓存。

    业务层的模式区分

    在业务层的模式上有几种选择。首先是过程式模式,在面向对象开发兴起之前,业务逻辑只不过是一系列过程的集合,每个集合都用来处理来自于表现层的一个请求。因此好的设计都在于更好的去组织这些过程,减少代码和流程的冗余。基于对象的模式抽象程度越高,与数据模型的差距也会越大,因此若想创建一个领域驱动的对象模型,一般应该从领域着眼,而不是从数据库结构开始。领域驱动的设计一定会使数据库模型和领域模型之间存在不小差异。这个模式通常叫做领域模型。

    基于对象的模式在开始时代价较高,但随着复杂性增长,其代价基本上也线性增加。换句话说,一旦你对领域模型有足够的了解,无论系统的复杂性如何,你都可以使用领域模型模式。在复杂性度量上,复杂性分为两方面,第一种是天生的,不可避免,无法协调需求本身,这类复杂性可以通过一些方法或多或少降低,不过不可能完全抹除,必须直接面对。第二种是来自于引入的复杂,这个来自于不同项目干系人意见的不协调,负面效果就是将团队引向错误的方向,错误的方向则会让抽象设计包含不必要或非功能性的功能,将软件逼上绝路。

    需求的数量可以用来粗略判断系统的复杂性,认识到复杂性比解释如何找到复杂性更加简单。

    事务脚本模式

    事务脚本模式可能是业务逻辑层中最简单的模式了,它是一个纯粹的过程式模式。事务脚本模式鼓励你放弃所有的面向对象设计,将业务直接映射到需要的用户操作上,该模式的关注点在于用户通过表现层所能执行的操作,并为每个操作编写一个专门的方法。事务脚本模式易于理解和解释,每个必须的用户操作都在一个物理事务中开始。直至结束,不过数据访问通常被封装在另一些组件中,并不属于脚本。事务脚本适合应用于那些业务逻辑非常简单,且最好不大可能改变的简单场景中。在这个简易度和复杂性的概念上权衡非常艰难,更为重要的是,对简单和复杂的认知还依赖与一个人的态度和能力。你懂的!

    简单是事务脚本模式最值得一提的优势,但是事务脚本有造成代码重复的潜质。所有实现了事务脚本的类型都可以看做是业务组件。每个业务组件都可以有一个或多个事务。比较流行的设计方式是将各个事务脚本分组,然后让每一组成为一个业务组件,这样每一组中的事务脚本在逻辑上都是相关的。另一种做法是将每个事务脚本用单独的类封装起来,这样每个业务组件都仅包含一个方法,换句话说,这里的业务组件就变成了一堆命令对象。若想将事务脚本的业务组件设计成命令对象,可以释放出一个接口,并将所有需要的参数以类型公有属性的形式暴露出来。

    表模块模式

    与事务脚本相比,表模块更有结构,表模块作为一个容器,将数据和行为组合在一起。业务逻辑被拆分为粗粒度的、表示整个数据表的组件。表模块的粒度不会下降到数据行的程度,即表模块类无法区分每一行数据。表模块模式应用中,使用基于记录集的数据结构是最常见的方式。例如Dataset、Datatable等。

    对那些不需要太多抽象,且数据模型和对象模型之间没有太大差异的场景,表模块是个非常不错的折衷方案。与事务脚本相比,表模块基于一个概念模型。而不是一大批方法的松散集合。若系统中的表现层和数据访问层都是基于表状数据结构,那么表模块将是非常好的选择,这时,业务层即可为表现层提供直接可用的数据,有时甚至可以直接通过数据绑定实现。

    表模块并没有比事务脚本复杂很多,不过若完全需要手工构造,那么花费的时间可能比简单的事务脚本多出很多。模式在提供了更多指导的同时,也意味着我们需要考虑更多规则,也就是编写更多代码。

    内嵌的Dataset设计器提供Fill和GetData方法来基于整个数据表进行查询。从概念角度讲,表模块的另一个优势在于,无论底层数据源是什么,对于同一些功能都会得到同样的表模块类。表模块基于对象,但完全由数据库驱动。表模块并不适合表述复杂的众多实体。特别是对象模型和数据模型之间有显著差距的时候。表模块的优势是VS提供了强大的支持,实现起来简单,不过考虑到这些生成的代码类似于一个黑箱,优势也就成了劣势。当然,表模块这个结构模型不一定需要和VS紧密耦合。

    活动记录模式

    事务脚本和表模块都是过程式模式。但是表模块基于对象,不是一个对于基于对象业务逻辑建模模式。最终走向面向对象设计关键的一步是你认识到系统中的目标对象,业务逻辑和领域逻辑才是系统的核心,它是由实体之间必须的交互组成的。

    活动记录是一种应用于相对简单的领域模型,但仍基于对象模式。另一种更加容易理解的说法是,活动记录基于数据表中的行,而不是表模块那样基于数据表。也就是说,活动记录对数据有行级别的粒度,而表模块关注的是整张表。活动记录模式归为数据源设计模式,而不是业务逻辑模式。活动记录模式就是指一个封装了数据表或视图的一行的对象,对象中可以同时包含数据和行为,活动记录对象的结构应该尽可能地接近于相关联的数据表结构。

    在那些没有服务层的应用程序中,活动记录模式可以和事务脚本结合使用。

    活动记录模式的成功依赖于两个因素:简单和框架。这两个因素紧密相关。我们最常见和熟悉的是LINQ- to - SQL。相对于简单的逻辑来说,活动记录非常合适。活动记录的另一个问题是对象和数据库表设计之间的绑定。若你不得不修改数据库,那么同时也要修改活动记录对象模型以及所有相关代码,从这个角度看,活动记录站在了领域驱动的对立面。

    领域驱动模式

    在设计领域逻辑时,若选用了过程式方法或活动记录模式,那么实际上采取的是以数据为核心的做法。驱动业务模型设计的并不是业务本身,而是业务中使用到的数据。

    从长远看,以数据为中心的方法并不能很好的适应规模的增加。因为当系统的复杂性达到某个极限之后,哪怕是再添加一些新的需求,都会成为难处理的问题。领域模型关注于系统的期待行为以及系统正常工作所需要的数据。领域驱动设计力求将复杂性控制在一个可控(虽然仍旧很高)范围内,选用领域驱动设计并不一定需要使用领域模型模式,不过领域模型模式是最自然的选择。

    领域模型描述了系统中涉及的实体,捕获了实体之间的关系以及数据在其中交换的过程。领域模型此刻还并不是一个软件,也不涉及任何软件或实现上的概念或原则。领域模型只是一个正式的模型,用来让技术团队和业务团队彼此理解并能良好交流。领域模型可以看作是活动记录的“大哥”,领域模型完全和数据库独立,是一个尽可能贴近真实流程的模型。领域模型模式使系统建模非常自由灵活,无需考虑平台和数据库的约束。此外,领域驱动设计是一种看待设计的方式,因此技能和态度起到了重要的作用。

    在领域模型中,概念是用来建模的,这种做法充分利用了面向对象设计的优势,你可以使用到面向对象的所有特性,包括封装和继承,而同时又无需受到数据库结构的限制,这就意味着实体并不会察觉到丝毫有关底层使用的持久化机制。领域模型是由需求驱动的,且仅需要你理解问题领域,并用类对于逻辑建模。实现领域模型主要的障碍是对象和关系型数据库之间的不匹配,领域模型是一个面向对象的设计,和数据库或其他应用程序的约束完全无关,而今受限于其建模的业务流程,这意味着同样的领域模型可以重用于其他需要同样逻辑的任意场景。模型是和业务相关的,且仅和业务相关。

    若没有任何O/R映射工具,例如NHibernate,那么很难实现领域模型模式。

    小结

    业务逻辑是系统的核心,不过并不是整个系统。业务逻辑设计上的选择将会影响到其他层,特别是持久化和数据访问层,这两个层加起来,就会项目的成败产生决定的影响。

    相关博客:


    展开全文
  • NET C# 企业级应用架构设计的第二版,高清扫描版,带有详细目录书签,学习架构的你绝对值得拥有
  • 讲授风格独特,提供详细上课日志及答疑,赠送配套的项目架构源码注释详细清晰且表达通俗,均能直接在实际项目中应用,正真的物超所值,价格实惠 任务作业: 综合运用《C#/.Net企业级系统架构设计实战精讲教程》课程...
  • Java企业级应用架构设计中的分布式结构  2010-12-24 13:54:12| 分类:默认分类 | 标签:|字号大中小 订阅 Java企业级应用架构设计是每个Java开发者不必学的知识,本文将对Java EE应用的架构与...

    Java企业级应用架构设计中的分布式结构  

    2010-12-24 13:54:12|  分类:默认分类 |  标签:|字号 订阅

    • Java企业级应用架构设计是每个Java开发者不必学的知识,本文将对Java EE应用的架构与设计进行一些基础性的介绍,而这些内容构筑了整个Java EE应用开发的基础。
    • Java企业级应用架构设计中的分布式结构大致可以分为单级结构、2级结构、3级结构和N级结构。充分理解和应用分布式结构可以更好的理解当代网络计算的现状,设计出更优的企业级应用程序。

      长久以来,Java企业级版本(Java EE)已经成为了众多产业领域(如银行业、保险业、零售业、酒店业、旅游业以及电信业等等)进行企业商务应用开发和部署的平台选择。Java EE之所以应用如此广泛,其原因在于,Java EE可以为构建健壮、高扩展性的分布式应用系统提供标准化的平台,而这些应用所支持的范围可以涵盖从银行核心业务运作,到航空公司订票引擎之间的广大区域。不过,开发成功的Java EE应用也可能成为一项艰巨的任务,Java企业级应用架构设计在其中起着重要作用。

      首先Java EE平台自身所提供的丰富选择就足可以令人生畏。那些过剩的框架、实用程序类库、集成开发环境(IDE),以及可供选择的工具让一切都更加富有挑战性。因此,选择好合适的技术对于开发基于Java EE的软件来说至关重要。而那些拥有健壮架构与设计准则的技术,会对构建易于维护、重用以及扩展的应用系统大有裨益。

      我们将首先回顾一下分布式计算的进化史以及n级结构。之后我将展示Java EE平台是如何解决分布式应用开发中的难点的。同时你还会了解模型-视图-控制器(MVC)结构准则。然后我会结合MVC准则与Java EE平台,来讲解多层Java EE应用结构。

      在了解了应用系统架构之后,我将把注意力集中到基于面向对象原则的Java EE应用开发上。我同时还会讲解如何使用设计模式来简化设计过程,以及如何选择最佳的实践范例。此外我还会触及Sun公司的Java BluePrints所收录的设计模式目录,其内容在Deepak Alur et al的《核心J2EE设计模式》(Prentice Hall出版社,2003年)一书中有详细的介绍。在文章的最后,我将介绍通用建模语言(UML)以及其在可视化Java EE文档设计与架构之中所扮演的的角色。

      分布式计算进化史

      在分布式计算中,一个应用会被划分为若干稍小的部件,并同时运行在不同的计算机上。这种计算方式又被称为“网络计算”,因为这些部件通常会通过建立在TCP/IP或者UDP协议之上的某些协议进行通讯。这些稍小的应用部件被称为“级”,每一级都可以向其他连接级独立提供一类服务。而“级”又可以被细化为若干“层”,以便降低功能的粒度。大多数Java企业级应用架构设计都应具有三个不同的层:

      ◆表现层负责用户接口。

      ◆业务层执行业务逻辑。在运行过程中,它还会与数据访问层进行交互。

      ◆数据访问层负责对存储在企业信息系统(EIS)中的数据进行存取等操作。

      通过分析分布式计算结构的跃迁史,我们可以更好的理解当代网络计算的现状。在接下来的几节中,我将用几个恰当的例子介绍分布式结构的变迁。

      单级结构
       
      单级结构的使用可以追溯到那些使用简易终端连接巨型主机的日子。在这种结构中,用户接口、业务逻辑以及数据等所有应用构成层都被配置在同一个物理主机中。用户通过终端机或控制台与系统进行交互,而这种方式只具有非常有限的文本处理能力(参见图1)

      Java企业级应用架构设计中的单层结构
      图1. 单层结构(图中文字:Console——“控制台”;Dumb Terminal——“简易终端”;Mainframe——主机)

      2级结构
       
      在1980年代早期,个人电脑(PC)变得非常流行,它比大型主机便宜,处理能力又比简易终端之类的设备强。PC的出现为真正的分布式(客户端——服务器,C/S)计算铺平了道路。作为客户端的PC现在可以独立运行客户接口(UI)程序,同时它还支持图形化客户接口(GUI),允许用户输入数据,并与服务器主机进行交互,而服务器主机现在只负责业务逻辑和数据的部分。当用户在客户端完成数据录入后,GUI程序可以选择性的进行数据有效性校验,之后将数据发送给服务器进行业务逻辑处理。Oracle基于表单的应用就是2级结构的优秀范例。表单的GUI存储在客户端PC中,而业务逻辑(包括代码以及存储过程)以及数据仍然保留在Oracle的数据库服务器中。

      此后又出现了另外一种2级结构,在这种结构中,不只是用户接口(UI),连业务逻辑也被放到了客户端一级。这种应用的典型运行方式是直接连接数据库服务器进行各种数据库查询。这种客户端被称作“胖客户端”,因为这种结构将可执行代码的相当大一部分都放到了客户端一级(参见图2)。

      Java企业级应用架构中的2级结构
      图2. 2级结构(Business Logic Layer——业务逻辑层;Optional——可选;User Interface Layer——用户接口层;Thick Client——胖客户端;Data Access Layer——数据访问层; Mainframe Server——服务器主机)

      3级结构

      尽管2级“胖客户端”应用的开发很简单,但是任何用户接口或者业务逻辑的改变所导致的软件升级都需要在所有客户端上进行。幸运的是,在上世纪90年代中期,硬件成本已经变得越来越低,而CPU的运算能力却得到了巨大提升。与此同时,互联网的发展非常迅速,互联网应用的发展趋势已经逐渐显现,两者的结合最终导致了3级结构的产生。

      在3级结构模型中,PC客户端只需要安装“瘦客户端”软件——比如浏览器——来显示服务器提供的展示内容,服务器负责准备展示内容、业务逻辑以及数据访问逻辑,应用程序的数据来自企业信息系统,例如关系数据库。在这样的系统中,业务逻辑可以通过远程访问,因此通过Java控制台应用程序支持一个独立的客户端就成为课程。业务层主要通过数据访问层与信息系统实现交互。因为整个应用都位于服务器之上,因此这样的服务器也被称作“应用程序服务器”或者“中间件”(参见图3)。

      Java企业级应用架构中的3级结构
      图3. 3级结构(图中文字:Presentation Layer——表现层;Business Logic Layer——业务逻辑层;Data Access Layer——数据访问层;Thin Client——瘦客户端;Application Server——应用程序服务器;Enterprise Data——企业数据;Database Server——数据库服务器)

      N级结构
       
      随着互联网带宽的不断提高,全世界的各大企业都相继启动了他们的网络服务。这种变化导致应用服务器无法继续承担表现层的巨大负荷。这项任务现在已经由专门负责产生展示内容的专门网页服务器所承担。展示内容之后被传送到客户端级的浏览器上,浏览器会负责将用户接口表现出来。N级结构中的应用服务器负责提供可远程访问的业务逻辑组件,而表现层网页服务器则使用本网协议通过网络访问这些组件。图4展示了n级结构。

      Java企业级应用架构中的N级结构 

      以上是Java企业级应用架构设计中的分布式结构,在不同的需求和应用场景中,我们会用到不同的分布式结构,设计不同的Java企业级应用架构。


    展开全文
  • .NET企业级应用架构设计系列

    千次阅读 2011-01-24 23:47:00
    一、.NET企业级应用架构设计系列之技术选型这里说的技术选型实际上是指技术方向的选择,或者叫平台方案的选择,也或者叫技术路线等,总之是大方向的把握。假定项目背景是要做一个中型WEB系统,公司组建新的技术团队...
  • .Net企业级应用架构设计之UML

    千次阅读 2012-09-07 22:33:02
    这篇博客之所讲UML出现在了《Microsoft.Net企业级应用架构设计》一书的第二章,从架构上讲不应该出现这节知识点,但是从架构师的职责角度,UML知识点是一个基础,因此作者独立出了一个章节。大家在学生时代都有学习...
  • 用三层架构设计模式思想部署企业级数据库业务系统开发.doc
  • 前段时间刚刚看完了《Microsoft .Net企业级应用架构设计》一书,以后陆续的分享作者在书中的精华,简明扼要的进行总结和概述。同时这本书推荐给有兴趣的童鞋。软件架构到底是什么 每次遇到软件项目时,我们都会创建...
  • 架构设计之道在于针对企业的现状和未来的战略目标及业务场景给出优雅合适的解决方案和演进的预期为企业降本增效。 一 隔离业务与技术细节,回归业务和技术的本质,促进业务与技术的协同 优秀的架构师需要具备...
  • 很多架构师不太重视表现层,仅将表现层作为业务层和数据访问层完成后的一个细节处理。但实际上,用户界面、业务逻辑和数据访问代码在任何一个系统中都是同等重要的。你的态度、偏好和自身的专业技能决定了你为每个层...
  •  .NET企业级应用架构设计系列之开场白 .NET企业级应用架构设计系列之技术选型 这里要说到的是关于三层架构中的应用服务器。对于电子商务网站来说,成熟的架构基本上都是采用分层式的。分层的结构一方面适合人脑的...
  • 在领域模型模式中,我们大都是将服务层看作是业务层的一部分。虽然这个做法非常常见,不过显然,我们还有其他选择。通常来说,服务层为表现层定义了一个接口,从而允许表现层触发一些预定义的系统操作。正如名称表现...
  • 基本设计原则 写出可以正常工作的代码是一回事,写出可以正常工作的良好代码则是另外一回事。一个设计精良的系统并不是一系列指令和修补的堆砌,里面还有很多与设计直接或间接相关的东西。与国际化标准中定义的其他...
  • 中台之上:商业银行业务架构设计

    千次阅读 2020-01-09 09:58:26
    从实际操作的角度讲,企业级业务架构设计及其建模过程是一个充满可能性和争议的过程,并没有一个直观的量化标准能够用于判断一个架构方案的好坏,下面通过一个虚拟的例子体会一下这种“难标准”的标准化过程。...
  • 企业级架构是什么?

    万次阅读 2017-05-15 11:35:04
    企业级架构的定义一个合理的定义是:企业级架构是一个组织的信息技术的规划和设计的过程和产物。 ~ Simplicable详细定义以下对企业级架构进行了详细定义:企业级架构是一个组织技术进行设计的过程,包括: 1. 业务和...
  • 在前端架构设计这块也已经工作了一段时间,也翻遍了很多书籍,但是就目前来说笔者还是没有看过真正把前端架构讲好的书,加上现在前端技术的发展诞生了许多新的框架,如:vue、react、angular,这也越来越淡化了前端...
  • J2EE企业级应用架构简述

    千次阅读 2017-02-07 21:48:51
    J2EE企业级应用架构简述1.课程设计: A.了解企业应用架构 B.了解服务治理的方式 C.掌握远程调用的基础 D.掌握使用Dubbo开发分布式服务2.分布式服务基础概念 A.分布式服务框架是企业级应用的基础 B.分布式服务...
  • 用三层架构设计模式思想部署企业级数据库业务系统开发 .rar
  • (这里,绝不要把架构设计孤立起来看待,它不只是规划期的事情,因为架构设计是对未来的把握,任何影响因素都要尽可能的考虑进来,特别是一些重大影响因素)。 上面的三点,是一个相互联系的整体,合在一起就成了...
  • .Net企业级应用架构设计之数据访问层

    千次阅读 多人点赞 2012-09-12 12:17:01
    综述 数据访问层的设计很大程度上取决于项目干系人需求的影响。例如,数据访问层应该持久化对象模型还是简单的的值的集合?数据访问层应该支持一种数据库还是多种数据库?下面仔细分析数据访问层的常见功能需求。 ...
  • Java企业级应用架构

    千次阅读 2010-09-14 21:43:00
    Java企业级应用架构设计中的分布式结构大致可以分为单级结构、2级结构、3级结构和N级结构。充分理解和应用分布式结构可以更好的理解当代网络计算的现状,设计出更优的企业级应用程序。 <br /> 长久以来...
  • 企业级架构的价值体现在哪里?

    千次阅读 2017-06-27 13:50:19
    企业级架构 (Enterprise architecture,EA) 是对包括业务和技术在内的组织结构管理的实践。这是一个远远超出大多数企业级架构团队预算、能力和影响力的巨大任务。因此,EA 团队通常开发一个价值主张,但这只是企业...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 137,579
精华内容 55,031
关键字:

企业级业务架构设计