企业应用架构模式设计

需积分: 9 77 浏览量更新于2024-07-19 收藏 4.65MB PDF 举报

Systems Engineering - EAA - Patterns of Enterprise Application Architecture 本资源摘要信息中，我们将对 Systems Engineering - EAA - Patterns of Enterprise Application Architecture 进行详细的解读和分析，涵盖标题、描述、标签和部分内容中的关键知识点。 **架构模式** 架构模式是企业应用架构的核心组件之一，在 Patterns of Enterprise Application Architecture 一书中，作者 Martin Fowler 等人对架构模式进行了深入的探讨。架构模式指的是在企业应用架构中，为了解决特定问题或满足特定需求而设计的解决方案。 **企业应用架构** 企业应用架构是指企业内部的应用系统的整体架构设计，旨在提供一个集成的解决方案，以满足企业的业务需求。在本书中，作者对企业应用架构进行了深入的分析，涵盖了架构模式、架构设计、性能优化等方面。 **应用架构层** 应用架构层是企业应用架构的组成部分之一，指的是应用系统的逻辑结构设计。作者在书中对应用架构层进行了详细的分析，涵盖了层次设计、领域逻辑设计、数据映射设计等方面。 **领域逻辑** 领域逻辑是企业应用架构的核心组件之一，指的是企业的业务逻辑设计。在本书中，作者对领域逻辑进行了深入的分析，涵盖了领域模型设计、业务规则设计、应用逻辑设计等方面。 **数据映射** 数据映射是企业应用架构中的一个关键组件，指的是将业务数据映射到关系数据库中的过程。作者在书中对数据映射进行了详细的分析，涵盖了结构映射模式、 metadata 设计、数据库连接设计等方面。 **Web 表现** Web 表现是企业应用架构中的一个重要组件，指的是将业务逻辑展示给最终用户的过程。在本书中，作者对 Web 表现进行了深入的分析，涵盖了视图模式、输入控制器模式、服务器端渲染等方面。 **并发性** 并发性是企业应用架构中的一个关键挑战，指的是多个用户同时访问应用系统时的性能问题。作者在书中对并发性进行了深入的分析，涵盖了并发问题、执行上下文、隔离和不可变设计等方面。本资源摘要信息中，我们对 Systems Engineering - EAA - Patterns of Enterprise Application Architecture 进行了详细的解读和分析，涵盖了架构模式、企业应用架构、应用架构层、领域逻辑、数据映射、Web 表现、并发性等关键知识点。

Thinking About Performance

Many architectural decisions are about performance. For most performance issues I prefer to get a system up

and running, instrument it, and then use a disciplined optimization process based on measurement. However,

some architectural decisions affect performance in a way that's difficult to fix with later optimization. And

even when it is easy to fix, people involved in the project worry about these decisions early.

It's always difficult to talk about performance in a book such as this. The reason that it's so difficult is that any

advice about performance should not be treated as fact until it's measured on your configuration. Too often I've

seen designs used or rejected because of performance considerations, which turn out to be bogus once

somebody actually does some measurements on the real setup used for the application.

I give a few guidelines in this book, including minimizing remote calls, which has been good performance

advice for quite a while. Even so, you should verify every tip by measuring on your application. Similarly

there are several occasions where code examples in this book sacrifice performance for understandability.

Again it's up to you to apply the optimizations for your environment. Whenever you do a performance

optimization, however, you must measure both before and after, otherwise, you may just be making your code

harder to read.

There's an important corollary to this: A significant change in configuration may invalidate any facts about

performance. Thus, if you upgrade to a new version of your virtual machine, hardware, database, or almost

anything else, you must redo your performance optimizations and make sure they're still helping. In many

cases a new configuration can change things. Indeed, you may find that an optimization you did in the past to

improve performance actually hurts performance in the new environment.

Another problem with talking about performance is the fact that many terms are used in an inconsistent way.

The most noted victim of this is "scalability," which is regularly used to mean half a dozen different things.

Here are the terms I use.

Response time is the amount of time it takes for the system to process a request from the outside. This may be

a UI action, such as pressing a button, or a server API call.

Responsiveness is about how quickly the system acknowledges a request as opposed to processing it. This is

important in many systems because users may become frustrated if a system has low responsiveness, even if

its response time is good. If your system waits during the whole request, then your responsiveness and

response time are the same. However, if you indicate that you've received the request before you complete,

then your responsiveness is better. Providing a progress bar during a file copy improves the responsiveness of

your user interface, even though it doesn't improve response time.

Latency is the minimum time required to get any form of response, even if the work to be done is nonexistent.

It's usually the big issue in remote systems. If I ask a program to do nothing, but to tell me when it's done

doing nothing, then I should get an almost instantaneous response if the program runs on my laptop. However,

if the program runs on a remote computer, I may get a few seconds just because of the time taken for the

request and response to make their way across the wire. As an application developer, I can usually do nothing

to improve latency. Latency is also the reason why you should minimize remote calls.

Throughput is how much stuff you can do in a given amount of time. If you're timing the copying of a file,

throughput might be measured in bytes per second. For enterprise applications a typical measure is

transactions per second (tps), but the problem is that this depends on the complexity of your transaction. For

your particular system you should pick a common set of transactions.

In this terminology performance is either throughput or response time—whichever matters more to you. It can

sometimes be difficult to talk about performance when a technique improves throughput but decreases

response time, so it's best to use the more precise term. From a user's perspective responsiveness may be more

important than response time, so improving responsiveness at a cost of response time or throughput will

increase performance.

Load is a statement of how much stress a system is under, which might be measured in how many users are

currently connected to it. The load is usually a context for some other measurement, such as a response time.

Thus, you may say that the response time for some request is 0.5 seconds with 10 users and 2 seconds with 20

users.

Load sensitivity is an expression of how the response time varies with the load. Let's say that system A has a

response time of 0.5 seconds for 10 through 20 users and system B has a response time of 0.2 seconds for 10

users that rises to 2 seconds for 20 users. In this case system A has a lower load sensitivity than system B. We

might also use the term degradation to say that system B degrades more than system A.

Efficiency is performance divided by resources. A system that gets 30 tps on two CPUs is more efficient than

a system that gets 40 tps on four identical CPUs.

The capacity of a system is an indication of maximum effective throughput or load. This might be an absolute

maximum or a point at which the performance dips below an acceptable threshold.

Scalability is a measure of how adding resources (usually hardware) affects performance. A scalable system is

one that allows you to add hardware and get a commensurate performance improvement, such as doubling

how many servers you have to double your throughput. Vertical scalability, or scaling up, means adding more

power to a single server, such as more memory. Horizontal scalability, or scaling out, means adding more

servers.

The problem here is that design decisions don't affect all of these performance factors equally. Say we have

two software systems running on a server: Swordfish's capacity is 20 tps while Camel's capacity is 40 tps.

Which has better performance? Which is more scalable? We can't answer the scalability question from this

data, and we can only say that Camel is more efficient on a single server. If we add another server, we notice

that swordfish now handles 35 tps and camel handles 50 tps. Camel's capacity is still better, but Swordfish

looks like it may scale out better. If we continue adding servers we'll discover that Swordfish gets 15 tps per

extra server and Camel gets 10. Given this data we can say that Swordfish has better horizontal scalability,

even though Camel is more efficient for less than five servers.

When building enterprise systems, it often makes sense to build for hardware scalability rather than capacity or

even efficiency. Scalability gives you the option of better performance if you need it. Scalability can also be

easier to do. Often designers do complicated things that improve the capacity on a particular hardware

platform when it might actually be cheaper to buy more hardware. If Camel has a greater cost than Swordfish,

and that greater cost is equivalent to a couple of servers, then Swordfish ends up being cheaper even if you

only need 40 tps. It's fashionable to complain about having to rely on better hardware to make our software run

properly, and I join this choir whenever I have to upgrade my laptop just to handle the latest version of Word.

But newer hardware is often cheaper than making software run on less powerful systems. Similarly, adding

more servers is often cheaper than adding more programmers—providing that a system is scalable.

Patterns

Patterns have been around for a long time, so part of me doesn't want to regurgitate their history yet another

time. Still, this is an opportunity for me to provide my view of patterns and what makes them a worthwhile

approach to describing design.

There's no generally accepted definition of a pattern, but perhaps the best place to start is Christopher

Alexander, an inspiration for many pattern enthusiasts: "Each pattern describes a problem which occurs over

and over again in our environment, and then describes the core of the solution to that problem, in such a way

that you can use this solution a million times over, without ever doing it the same way twice" [

Alexander et

al.]. Alexander is an architect, so he was talking about buildings, but the definition works pretty nicely for

software as well. The focus of the pattern is a particular solution, one that's both common and effective in

dealing with one or more recurring problems. Another way of looking at it is that a pattern is a chunk of advice

and the art of creating patterns is to divide up many pieces of advice into relatively independent chunks so that

you can refer to them and discuss them more or less separately.

A key part of patterns is that they're rooted in practice. You find patterns by looking at what people do,

observing things that work, and then looking for the "core of the solution." It isn't an easy process, but once

you've found some good patterns they become a valuable thing. For me their value lies in being able to create

a book that serves as a reference. You don't need to read all of this book, or all of any patterns book, to find it

useful. You just need to read enough to have a sense of what the patterns are, what problems they solve, and

how they solve them. You don't need to know all the details but just enough so that if you run into one of the

problems you can find the pattern in the book. Only then do you need to really understand the pattern in depth.

Once you need the pattern, you have to figure out how to apply it to your circumstances. A key thing about

patterns is that you can never just apply the solution blindly, which is why pattern tools have been such

miserable failures. I like to say that patterns are "half baked," meaning that you always have to finish them off

in the oven of your own project. Every time I use a pattern I tweak it a little here and a little there. You see the

same solution many times over, but it's never exactly the same.

Each pattern is relatively independent, but patterns aren't isolated from each other. Often one pattern leads to

another or one occurs only if another is around. Thus, you'll usually only see

Class Table Inheritance (285) if

there's a

Domain Model (116) in your design. The boundaries between the patterns are naturally fuzzy, but I've

tried to make each pattern as self-standing as I can. If someone says "Use a

Unit of Work (184)," you can look

it up and see how to apply it without having to read the entire book.

If you're an experienced designer of enterprise applications, you'll probably find that most of these patterns are

familiar to you. I hope you won't be too disappointed (I did try to warn you in the Preface). Patterns aren't

original ideas; they're very much observations of what happens in the field. As a result, we pattern authors

don't say we "invented" a pattern but rather that we "discovered" one. Our role is to note the common solution,

look for its core, and then write down the resulting pattern. For an experienced designer, the value of the

pattern is not that it gives you a new idea; the value lies in helping you communicate your idea. If you and

your colleagues all know what a

Remote Facade (388) is, you can communicate a lot by saying, "This class is

a Remote Facade." It also allows you to say to someone newer, "Use a Data Transfer Object for this," and they

can come to this book to look it up. The result is that patterns create a vocabulary about design, which is why

naming is such an important issue.

While most of these patterns are truly for enterprise applications, those in the base patterns chapter (Chapter

18) are more general and localized. I include them because I refer to them in discussions of the enterprise

application patterns.

The Structure of the Patterns

Every author has to choose his pattern form. Some base their forms on a classic patterns book such as

[

Alexander et al.], [Gang of Four], or [POSA]. Others make up their own. I've long wrestled with what makes

the best form. On the one hand I don't want something as small as the GOF form; on the other hand I need to

have sections that support a reference book. So this is what I've used for this book.

The first item is the name of the pattern. Pattern names are crucial, because part of the purpose of patterns is to

create a vocabulary that allows designers to communicate more effectively. Thus, if I tell you my Web server

is built around a

Front Controller (344) and a Transform View (361) and you know these patterns, you have a

very clear idea of my web server's architecture.

Next are two items that go together: the intent and the sketch. The intent sums up the pattern in a sentence or

two; the sketch is a visual representation of the pattern, often but not always a UML diagram. The idea is to

create a brief reminder of what the pattern is about so you can quickly recall it. If you already "have the

pattern," meaning that you know the solution even if you don't know the name, then the intent and the sketch

should be all you need to know what the pattern is.

The next section describes a motivating problem for the pattern. This may not be the only problem that the

pattern solves, but it's one that I think best motivates the pattern.

How It Works describes the solution. In here I put a discussion of implementation issues and variations that

I've come across. The discussion is as independent as possible of any particular platform—where there are

platform-specific sections I've indented them so you can see them and easily skip over them. Where useful I've

put in UML diagrams to help explain them.

When to Use It describes when the pattern should be used. Here I talk about the trade-offs that make you select

this solution compared to others. Many of the patterns in this book are alternatives; such

Page Controller (333)

and

Front Controller (344). Few patterns are always the right choice, so whenever I find a pattern I always ask

myself, "When would I not use this?" That question often leads me to alternative patterns.

The Further Reading section points you to other discussions of this pattern. This isn't a comprehensive

bibliography. I've limited my references to pieces that I think are important in helping you understand the

pattern, so I've eliminated any discussion that I don't think adds much to what I've written and of course I've

eliminated discussions of patterns I haven't read. I also haven't mentioned items that I think are going to be

hard to find, or unstable Web links that I fear may disappear by the time you read this book.

I like to add one or more examples. Each one is a simple example of the pattern in use, illustrated with some

code in Java or C#. I chose those languages because they seem to be languages that the largest number of

professional programmers can read. It's absolutely essential to understand that the example is not the pattern.

When you use the pattern, it won't look exactly like this example so don't treat it as some kind of glorified

macro. I've deliberately kept the example as simple as possible so you can see the pattern in as clear a form as

I can imagine. All sorts of issues are ignored that will become important when you use it, but these will be

particular to your own environment. This is why you always have to tweak the pattern.

One of the consequences of this is that I've worked hard to keep each example as simple as I can, while still

illustrating its core message. Thus, I've often chosen an example that's simple and explicit, rather than one that

demonstrates how a pattern works with the many wrinkles required in a production system. It's a tricky

balance between simple and simplistic, but it's also true that too many realistic yet peripheral issues can make

it harder to understand the key points of a pattern.

This is also why I've gone for simple independent examples instead of a connected running examples.

Independent examples are easier to understand in isolation, but give less guidance on how you put them

together. A connected example shows how things fit together, but it's hard to understand any one pattern

without understanding all the others involved in the example. While in theory it's possible to produce

examples that are connected yet understandable independently, doing so is very hard—or at least too hard for

me—so I chose the independent route.

The code in the examples is written with a focus on making the ideas understandable. As a result several

things fall aside—in particular, error handling, which I don't pay much attention to since I haven't developed

any patterns in this area yet. They are there purely to illustrate the pattern. They are not intended to show how

to model any particular business problem.

For these reasons the code isn't downloadable from my Web site. Each code example in this book is

surrounded with too much scaffolding to simplify the basic ideas so they're worth anything in a production

setting.

Not all the sections appear in all the patterns. If I couldn't think of a good example or motivation text, I left it

out.

Limitations of These Patterns

As I indicated in the Preface, this collection of patterns is by no means a comprehensive guide to enterprise

application development. My test for this book is not whether it's complete but merely if it's useful. The field

is too big for one mind, let alone one book.

The patterns here are all ones that I've seen in the field, but I'm not going to claim I completely understand all

of their ramifications and interrelationships. This book reflects my current understanding, and that

understanding has developed as I've been writing the book. I expect it will continue to evolve long after this

book has turned into paper. One certainty of software development is that it never stands still.

As you consider using the patterns, never forget that they're a starting point, not a final destination. There's no

way that any author can see all the many variations that software projects have. I've written these patterns to

help provide a beginning, so you can read about lessons that I, and the people I've observed, have learned from

剩余388页未读，继续阅读

simonsun315

粉丝: 0
资源: 3

企业应用架构模式设计

房地产全民经纪人方案-eaa7bf35e55c3b3567ec102de2bd960591c6d916.zip

11-网络管理和监控配置指导-EAA配置.pdf

co-co-eaa：基于内聚耦合的事件抽象方法

iOS实例开发源码——fcarucci-Diamonds-d0eaa94.zip

iOS游戏应用源代码——fcarucci-Diamonds-d0eaa94.zip

vlasovmaksim-nsbench-1dc3eaa9ab01_sdfdsf_zip_

EAA行业(2021-2026)企业市场突围战略分析与建议.docx

多媒体播放插件eAA

podman-1.0.0-6.git921f98f.module_el8.4.0+653+7095eaa9.x86_64.rpm

EAA公司（行业）薪酬管理制度方案-薪酬设计方案资料文集系列.docx

最新资源