企业应用架构模式：经典设计原则与解决方案

需积分: 10 116 浏览量更新于2024-07-17 收藏 3.09MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

《企业应用架构模式》(Patterns of Enterprise Application Architecture)是于2002年11月5日由Addison Wesley出版社出版的一本著作，作者是知名的对象导向设计专家马丁·福勒(Martin Fowler)。该书针对企业应用开发领域面临的挑战而编写，随着技术的发展，如Smalltalk、CORBA、Java到.NET的演变，作者认识到尽管工具和技术在不断更新，但核心的设计理念仍然具有普适性。书中阐述了在多层对象导向平台如Java和.NET等广泛使用的背景下，企业应用开发中的常见问题和挑战。作者指出，许多开发者在构建复杂系统时，由于缺乏对资深对象开发者所积累的架构经验的理解，导致了项目失败。为了帮助开发者避免这些问题，马丁·福勒与一群专家合作，提炼出了四十多个反复出现的解决方案，将它们形式化为设计模式。这些模式涵盖了企业应用架构的各个方面，包括但不限于：分层架构、模块化、事务管理、安全模型、服务定位和服务整合等。它们不仅提供了实用的设计原则，还指导开发者如何在新技术环境中实现稳定、可扩展和易于维护的应用。例如，单体架构与微服务架构模式的区别，以及如何通过领域驱动设计(Domain-Driven Design, DDD)来处理复杂的业务逻辑。虽然这本书发表于2002年，但其核心思想和设计原则至今仍具有很高的参考价值。随着云计算、DevOps和云计算原生应用的兴起，很多古老的问题依然存在，而《企业应用架构模式》提供的模式和最佳实践为现代开发者提供了宝贵的指引，帮助他们在不断变化的技术环境中进行明智的设计决策。通过阅读这本书，读者不仅能掌握如何有效地运用各种技术工具，还能深入理解软件架构背后的原则，从而提升企业应用的健壮性、性能和整体质量。对于任何参与企业级软件开发的人来说，无论是架构师、项目经理还是技术领导者，这都是一本不可多得的参考资料。

资源详情

资源推荐

Introduction

In case you haven't realized it, building computer systems is hard. As the

complexity of the system gets greater, the task of building the software gets

exponentially harder. As in any profession, we can progress only by learning, both

from our mistakes and from our successes. This book represents some of this learning

written in a form that I hope will help you to learn these lessons quicker than I

did, or to communicate to others more effectively than I did before I boiled these

patterns down.

In this introduction I want to set the scope of the book and provide some of the

background that will underpin its ideas.

Architecture

The software industry delights in taking words and stretching them into a myriad

of subtly contradictory meanings. One of the biggest sufferers is "architecture."

I tend to look at "architecture" as one of those impressive-sounding words, used

primarily to indicate that we're talking something that's important. But I'm

pragmatic enough not to let my cynicism get in the way of attracting people to my

book. :-)

"Architecture" is a term that lots of people try to define, with little agreement.

There are two common elements: One is the highest-level breakdown of a system into

its parts; the other, decisions that are hard to change. It's also increasingly

realized that there isn't just one way to state a system's architecture; rather,

there are multiple architectures in a system, and the view of what is

architecturally significant is one that can change over a system's lifetime.

From time to time Ralph Johnson has a truly remarkable posting on a mailing list,

and he did one on architecture just as I was finishing the draft of this book. In

this posting he brought out the point that architecture is a subjective thing, a

shared understanding of a system's design by the expert developers on a project.

Commonly this shared understanding is in the form of the major components of the

system and how they interact. It's also about decisions, in that it's the decisions

that developers wish they could get right early on because they're perceived as

hard to change. The subjectivity comes in here as well because, if you find that

something is easier to change than you once thought, then it's no longer

architectural. In the end architecture boils down to the important stuff—whatever

that is.

In this book I present my perception of the major parts of an enterprise application

and of the decisions I wish I could get right early on. The architectural pattern

I like the most is that of layers, which I describe more in Chapter 1. This book

is thus about how you decompose an enterprise application into layers and how these

layers work together. Most nontrivial enterprise applications use a layered

architecture of some form, but in some situations other approaches, such as pipes

and filters, are valuable. I don't go into those situations, focusing instead on

Enterprise Applications

Lots of people write computer software, and we call all of it software development.

However, there are distinct kinds of software out there, each of which has its own

challenges and complexities. This comes out when I talk with some of my friends in

the telecom field. In some ways enterprise applications are much easier than

telecoms software—we don't have very hard multithreading problems, and we don't

have hardware and software integration. But in other ways it's much tougher.

Enterprise applications often have complex data—and lots of it—to work on,

together with business rules that fail all tests of logical reasoning. Although

some techniques and patterns are relevant for all kinds of software, many are

relevant for only one particular branch.

In my career I've concentrated on enterprise applications, so my patterns here are

all about that. (Other terms for enterprise applications include "information

systems" or, for those with a long memory, "data processing.") But what do I mean

by the term "enterprise application"? I can't give a precise definition, but I can

give some indication of my meaning.

I'll start with examples. Enterprise applications include payroll, patient

records, shipping tracking, cost analysis, credit scoring, insurance, supply

chain, accounting, customer service, and foreign exchange trading. Enterprise

applications don't include automobile fuel injection, word processors, elevator

controllers, chemical plant controllers, telephone switches, operating systems,

compilers, and games.

Enterprise applications usually involve persistent data. The data is persistent

because it needs to be around between multiple runs of the program—indeed, it

usually needs to persist for several years. Also during this time there will be many

changes in the programs that use it. It will often outlast the hardware that

originally created much of it, and outlast operating systems and compilers. During

that time there'll be many changes to the structure of the data in order to store

new pieces of information without disturbing the old pieces. Even if there's a

fundamental change and the company installs a completely new application to handle

a job, the data has to be migrated to the new application.

There's usually a lot of data—a moderate system will have over 1 GB of data organized

in tens of millions of records—so much that managing it is a major part of the

system. Older systems used indexed file structures such as IBM's VSAM and ISAM.

Modern systems usually use databases, mostly relational databases. The design and

feeding of these databases has turned into a subprofession of its own.

Usually many people access data concurrently. For many systems this may be less than

a hundred people, but for Web-based systems that talk over the Internet this goes

up by orders of magnitude. With so many people there are definite issues in ensuring

that all of them can access the system properly. But even without that many people,

there are still problems in making sure that two people don't access the same data

at the same time in a way that causes errors. Transaction manager tools handle some

of this burden, but often it's impossible to hide this from application developers.

With so much data, there's usually a lot of user interface screens to handle it.

It's not unusual to have hundreds of distinct screens. Users of enterprise

applications vary from occasional to regular, and normally they will have little

technical expertise. Thus, the data has to be presented lots of different ways for

different purposes. Systems often have a lot of batch processing, which is easy

to forget when focusing on use cases that stress user interaction.

Enterprise applications rarely live on an island. Usually they need to integrate

with other enterprise applications scattered around the enterprise. The various

systems are built at different times with different technologies, and even the

collaboration mechanisms will be different: COBOL data files, CORBA, messaging

systems. Every so often the enterprise will try to integrate its different systems

using a common communication technology. Of course, it hardly ever finishes the

job, so there are several different unified integration schemes in place at once.

This gets even worse as businesses seek to integrate with their business partners

as well.

Even if a company unifies the technology for integration, they run into problems

with differences in business process and conceptual dissonance with the data. One

剩余634页未读，继续阅读

cdh111007

粉丝: 0
资源: 1

企业应用架构模式：经典设计原则与解决方案

Patterns of Enterprise Application Architecture.chm

Patterns of Enterprise Application Architecture

帮我找一下可以写再javaweb毕设里的英文参考文献

软件系统设计模式参考文献

!pip install mlxtend from mlxtend.preprocessing import TransactionEncoder from mlxtend.frequent_patterns import apriori from mlxtend.frequent_patterns import association_rules爆红，怎么解决

Polychronous spiking patterns emerge inside the reservoir.啥意思

head first design patterns-深入浅出设计模式.pdf

Android charts

druid: aop-patterns: com.yqn.* filters: stat,wall stat-view-servlet: enabled: true login-username: admin login-password: admin web-stat-filter: enabled: true url-pattern: /* logging: level: com.yqn.mapper: debug

软件架构师10大经典书籍

All the 5 fits failed. It is very likely that your model is misconfigured. You can try to debug the ...

Detailed explanation of how the set of individual think-aloud results was interpreted to determine the strengths and weaknesses above

Give me a project based on ArcGIS Pro

Fractal structure

design a DHNN to store a pattern then use the designed DHNN to recall the corrupted pattern

coflow scheduling frameworks

最新资源