Evolutionary architecture and emergent design: research architecture and design

Evolutionary architecture (evolutionary architecture) and emergency design (emergent) are agile technologies that postpone important decisions to the last-minute responsibility (responsible Moment). In the first installment of this series, Neal Ford, a series author, will define the architecture and design, and then indicate some basic concepts about the entire series.

There is no clear definition of software architecture and design, as software development as a discipline has not yet fully understood its complexity and connotation. But to publish a discussion of these topics, you must start somewhere. This series covers evolutionary architecture and emergent design, so it will start with definitions, considerations, and other basic settings.

Defining schemas

The architecture in the software is one of the most difficult concepts developers can talk about, but the hardest to understand. During the meeting, there are frequent conversations about architecture and related discussions, but we still have vague definitions. In discussing the architecture, we are essentially talking about several different but relevant aspects, which can often be divided into the two main categories of application architecture and enterprise architecture.

Application Architecture

The application schema describes the main components of the application. In the Java world, for example, the application architecture describes two things: a framework combination for building a particular application-I call it a framework-level architecture-and more traditional logical focus separation, which I've always called the application architecture. Take the framework architecture as a stand-alone part, because most object-oriented language practitioners have found that separate classes do not achieve good reuse (when was the last time you downloaded a separate class from the Internet for use by a project)? ）。 At present, the reuse part of object-oriented language is a library or framework. When you start a new project in a language that provides rich frameworks, such as the Java language, one of the primary architectural concerns is the framework-level architecture of the application. This reuse design has been so successful in the Java world that I have begun to think that we should stop calling Java programming an object-oriented language, but rather a framework-oriented language. In many ways, a framework-level architecture represents the physical architecture described by a particular building block.

Another interesting aspect of the application architecture describes how the logical parts of the application are integrated together. This belongs to the domain of design patterns and other architectural descriptions, and thus tends to be more abstract and logical, rather than physical. For example, you can say that WEB applications follow model-view-representation (Model-view-presenter) patterns without detailing which framework you use to implement logical arrangements. This logical arrangement is one of the most likely additions to the work Space Whiteboard (whiteboard) When you start processing new components of your application.

Enterprise Architecture

The enterprise architecture focuses on how to make the application available to the enterprise as a whole (typically an application that runs within a large organization). A common metaphor for the relationship between enterprise architecture and application architecture is to compare enterprises to urban planning, and to compare applications to building structures. Urban planners must consider access to water, electricity, sewage and other services in order for the city to function. A building can use no more tap water than a quota provided to it. The enterprise architecture needs to consider the same thing for the application: You cannot allow an application to use all network bandwidth, and if the infrastructure services crash, there will be a lot of problems.

The enterprise architecture has received a lot of attention over the past few years because of the service-oriented architecture (service-oriented Architecture,soa). SOA is a huge and independent subject, so future installments of this series will treat it as a special case. It has its own interesting aspect because it blurs the boundaries between an enterprise architecture and an application architecture when it sets the characteristics of an application construct.

The preceding paragraphs provide a surface definition of these important concepts, but they can be used as a starting point for other more interesting and detailed architectural definitions (including some defined by other definitions).

The current definition

Many talented people have tried to define the software architecture, so I will get some ideas from their results. In Martin Fowler's classic white paper "Who Needs a Architect?" , he discusses several definitions. He cites the first definition in the Extreme programming mailing list:

"Developing an IEEE-defined RUP defines the architecture as the highest level of system concepts in the environment." The architecture of a software system (at a particular point in time) is an organization or structure of important components that interact through interfaces, which are composed of increasingly small components and interfaces. ’”

As mentioned above, this definition is appropriate in the area of application architecture. Although somewhat vague, it captures the essence of architectural responsibility: the highest level of concept.

Fowler later quoted Ralph Johnson, Ralph Johnson's reply to this mailing list disputed the previous definition:

"A better definition is: ' In most successful software projects, the expert developers involved in the project have a common understanding of design system design." This consensus is called "architecture". This consensus includes how to divide the system into components and how the components interact through interfaces. ’”

Johnson puts forward a good point of view, emphasizing that software development relies more on communication than on technology, which actually represents a consensus about the system, rather than language, framework, and other ephemeral technologies.