Application Architecture nature, Part 1: getting started with Design Patterns

For application architects, the logo, app, and record patterns are as common as three meals a day. The model covers many complex aspects, from a large architecture of the application architecture to a specific design problem solution. To ensure successful design, you must consider and be able to apply the existing model. In this article, you will learn how to identify

For application architects, the logo, app, and record patterns are as common as three meals a day. The model covers many complex aspects, from a large architecture of the application architecture to a specific design problem solution. To ensure successful design, you must consider and be able to apply the existing model. In this article, you will learn how to identify

For application architects, the logo, app, and record patterns are as common as three meals a day. The model covers many complex aspects, from a large architecture of the application architecture to a specific design problem solution. To ensure successful design, you must consider and be able to apply the existing model. In this article, you will learn how to identify repeated patterns in the design and how to record their features, advantages, and disadvantages.

Models are required from requirements to the formation of an effective application architecture.ModelingIs the process of recording the state and behavior of the model in the application domain. These models need to be considered to help solve design problems. As time goes on, the intra-domain model will become a language for communication design advantages and disadvantages.

In part 2 of this series on the application architecture (this article), we will learn the skills, tools, and Milestones related to the design patterns to help you solve common problems. At least part of the design work needs to consider how to resolve conflicting needs, which are usually expressedForce). The pattern identifies the applicable influencing factors and provides a solution to reconcile these influencing factors.

Skills and abilities

As an application architect, you should be able to identify the impact factors involved in requirements and system design. You should be familiar with the existing mode and be able to identify and record the new domain-specific mode. Finally, you should be able to apply (or create mechanisms for other people to apply) various modes that are useful in the domain or system design.

Familiar with existing models

Familiarize yourself with the existing mode as much as possible. (See the link to the mode language and repository provided in the references section .) By fully understanding and understanding the existing mode, you can quickly identify and create the mode. However, please note that do not apply the existing mode to all design problems.

Id Mode

Identifying the patterns that apply in the demand set or system design is a major skill of the application architect. In this case, I do not think there should be any stages or activities related to the mode in the development lifecycle. Because the mode appears at various abstraction levels and involves multiple development activities, it can even be applied to the development model itself, this makes pattern identification and application come to mind when necessary and when emergency measures are taken against dangers, but you do not need to be too entangled in this aspect.

Record Mode

I would like to discuss two areas: record of pattern content and record of pattern usage. You should not only be able to create impact factors, context, and solution descriptions for easy-to-understand patterns, but also record patterns that identify, apply, or apply in design and implementation. Over time, through simple collection and refactoring, we should be able to build a wider range of pattern languages for application domains. I do not recommend that you record the mode every time at work. We are used to following patterns, and this natural drive force is irresistible. Record only important design methods that help improve the overall quality of the system.

Of course, you should be familiar with one or more industry methods and formats related to model records, and be familiar with any standards specific to your environment. For information about existing mode repositories and books, see the links provided in references.

Abstraction

As I mentioned in part 1 of this series, abstraction is a key skill in demand analysis. Undoubtedly, this is at least applicable to the effective use of the design model. When you change the design to meet new requirements, take a few steps back and abstract the details until you get the pivot point, you can handle specific types of changes at this pivot point without affecting existing elements. This will probably involve using existing models as candidate solutions to provide proper separation.

Most of the modes are based onPlug-Ability), Also knownTemplate-and-hook). Generic behaviors (templates) will be defined and domain-specific behaviors and statuses provided by the domain class (hooks are provided) will be provided ). This is the metadata model that is used as the basis for most models. Remember this when developing your own models.

Architecture Style

Architecture StyleProcess the whole or part of the overall structure of the application. A specific style provides improvements to one or more quality attributes of an application-typically at the cost of other attributes. For example, pipelines and filtering styles allow convenient combination and loose coupling between links. However, the distributability and predictability in this style are negatively affected. You should be familiar with most of the structure design principles-especially the Structure Design Principles of applications in your application domain. In addition, pay attention to the advantages and disadvantages of each style.

Modeling

As I mentioned in the first article in this series, modeling is a key skill for application architects. Most of the operations related to the design pattern are performed in the modeling field. Even the underlying encoding mode can be applied in this field, because Code can be considered another model of the solution. You should be able to use the modeling language implementation mode to use it in other projects, and you should be able to apply the existing mode to the model.

To implement the mode as a model, you must use the modeling language to create the template content of the mode. For the Unified Modeling Language (UML), this can be a single package, including the corresponding sub-packages, classes, relations and interfaces; or can be a complete Modeling project, it contains multiple models for various aspects of the mode solution. Regardless of the tool used for modeling, I have found a way to create these templates to reuse the entire architecture model or a single analysis model.

Currently, multiple modeling tools that process patterns as the primary concept are available. In these environments, you can create and apply models for models, and use various levels of automation to support ing mode roles to model objects. (For more information, see tools and technology .)

To apply a pattern to a model, you need to map general rules in the schema solution to a specific domain class in the model. To do this, you must add all the statuses and relationships required by the mode to the domain class. You may also want to change the common aspect name of the schema to match the corresponding language of the domain. For example, the accounting analysis model may include roles such as Account and Customer.getCustomerAndgetAccount. If your domain includesCreditCardAndMember, You may want to change the operationgetMemberAndgetCreditCard). Of course you should be able to perform this ing. If your tool does not automate this process, develop your own scripts or macros.

Back to Top

Tools and technology: breaking down applications

Modern Enterprise applications have become quite complex. The number of interdependent components involved in the application architecture is constantly increasing. However, we rarely take full advantage of the flexibility of this type of architecture. Let's take a look at the actual situation of the application and how the structure of the enterprise application is evolving into a "decomposition" application.

I will first give a simple definition of the application components.ApplicationsIs a constructor that provides access to computing resources to support specific purposes. Therefore, most applications contain the following components:

• Rule --Applications implement rules that specify Input and Output visibility.
• Workflow --An application defines a sequence of steps through a supported activity. Note that some applications are relatively "NO mode" and almost do not involve workflows. In addition, you can use the rules mentioned above to define a workflow.
• Subsystem integration --Applications can interact with one or more subsystems to provide controlled integration between these subsystems.
• Event --Event streams between application management and external systems and subsystems. This process can be very complex (for example, asynchronous event queue), or very simple (for example, calling the sub-system function repeatedly to call the behavior, read the status or the main loop of the propagation status ).
• Information Model --An application defines its Information Model Based on the subsystem. The information model is a combination view of subsystem status and application-specific status. Generally, applications must provide information ing between subsystems.
• Binding and propagation --Applications provide information models including external and dynamic configurations, subsystem status views, and application-specific status views. Most of the application code involves synchronizing the information between subsystems, responding to changes, and spreading changes to related components.

All of these have led to the emergence of patterns: with more and more common components that support application functions (such as rule engine, workflow engine, and Enterprise Service Bus ), applications will become increasingly vague and scattered, and the declaration specifications and configuration set of each application supporting components will become larger and larger. If you are an architect of a large enterprise, remember this. If you belong to a small enterprise, do not consider yourself as independent from the decomposition trend. Sooner or later (if you have not started), you will use this method to build the application.

Back to Top

Tools and technology: Layers

So far, I have discussed how to identify, record, and apply patterns in multiple abstract levels, throughout the entire application cycle, or even in the development lifecycle itself. With all these potential patterns, You need to organize them in some way. One way to limit the applicable mode is to classify the mode based on the hierarchy of the architecture to which it is applied.

The relationship diagram in Figure 1 shows a possible arrangement for different types of layers. The concept hierarchy (business, application, information and technology architecture) is displayed on the right. The vertical part is the logical hierarchy related to the application and information architecture. The bottom is the technical level, which shows how the logical level maps to the physical infrastructure. This arrangement shows a thin client deployment, all of which are mapped to the client physical layer with some application logic.

Figure 1. Layered ing

Concept Level

Concept LevelDivides a very abstract pattern space into business domain patterns, solution design patterns, and infrastructure patterns.

Logical hierarchy

Logical hierarchyDivide the mode space according to the hierarchical architecture functions. Logical layers can be defined in multiple ways, but generally divided into three or four levels:

• Indicates --Allows you to display and capture external events and request components.
• Application --Implement application stream, aggregate information, and call business transaction components.
• Business --Components that implement business entities, rules, processes, and transactions.
• Data --Provides components for accessing persistent data and other external data.

The logic layer is part of the application deployment architecture and is directed to the physical layer. These mappings also contain some common modes. For example,Thin clientOr the Independent Architecture maps all or most of the logical layers to the client physical layer. Distributed enterprise Web applications may distribute logical layers to a series of physical layers. Finally,Rich ClientThe architecture maps the presentation layer (including the application layer) to the client.

Application Architecture mode orPrototypeCovers all logic layers and defines the overall structure of the entire application. Other modes will be at a lower granularity level, acting on components or component interaction design at a single level. Another type of mode covers the interaction between two layers. This partitioning mode space method can at least help you find the starting point when looking for an existing mode or classifying a new mode.

Physical level

Physical levelThe mode space is divided by the physical deployment platform of the mode application. Patterns in this category are related to solving problems on specific platforms. For example, you can have a common session state management mode and multiple platform-specific modes, which are used in Microsoft®ASP. NET and assumerver Pages (JSP) sites implement the common mode.

J2EE

Java™2. The Platform Enterprise Edition (J2EE) Standard defines the logic layer of an application as a container stack. The defined containers include:

• Client container --Supports client access to application resources.
• Web Container --Process client requests and formatted data for display.
• EJB container --It provides an environment for high availability and high performance of business logic.
• Connector --Provides access to external resources such as databases and mainframes.

Back to Top

Tools and technology: Component Design Model

Component-based Software Engineering (CBSE) connects components through interfaces to construct a system. Important models include contractual design, well-defined interfaces, combiner, predictable behavior, and component testing. Currently, there are many modes and mode languages about component distribution, interaction, and construction. Here are some examples:

• Interactive Mode --The component interaction mode helps solve design problems related to the collaboration, communication, and coordination of components in the architecture. Similar to Architecture styles, these patterns process large structures of application architectures. For example, in the Abstract Interactions mode, we recommend that you define component interaction as an Abstract interface. By combining with the "Component Bus" (Component Bus) mode (and well-designed), you can create a flexible Component architecture without coupling.
• Distribution Mode --The component distribution mode processes problems and Influencing Factors Related to distributed components in different platforms and environments.
• Connection Mode --The component connection mode processes how components are "connected" Together (dynamic or static ).
• Behavior mode --The behavior mode of the component processes the interaction between the component and its environment.
• Deployment mode --The deployment mode helps process the influencing factors related to component deployment. For example, in a distributed component architecture, latency between components is sometimes unacceptable due to distributed overhead. The component packaging mode allows a balance between flexibility and other attributes of the distributed environment and the predictability of the interaction between local components.
• Business Component factory --The business component factory method is described in detail in the books written by Peter Herzum and Oliver Sims (see references ). This book provides a complete model framework to support the standardization, construction, and deployment of enterprise business components.
• Dependency injection -- Dependency InjectionIs a technology used to connect objects or components together. Dependency injection does not build components that initialize itself (including creating dependency objects), but provides a container (or factory ), to find or create a dependent object and call the setter hook for the requested object to initialize its reference. With this feature, you can easily reconfigure components and easily support pluggable designs to avoid hard-coding dependencies between components. A good example of this type of container is Spring (see references), an open-source container that supports dependency injection for a traditional Java Object (Plain Old Java Object, POJO. Components are connected together using the Extensible Markup Language (XML) configuration file.

Back to Top

Tools and technology: enterprise integration model

The enterprise integration mode discusses the large-scale integration of enterprise applications and systems. These models focus on communications between applications and other information system components. Messages (as well as message creation, routing, response, and conversion) are the main concepts in these modes.

Back to Top

Tools and technology: enterprise application model

Enterprise Application pattern handles design issues within the architecture of applications and their subsystems. These modes discuss the features of representation, ing to relational data storage, domain logic, application state management, and application creation.

Back to Top

Tools and technology: Analysis Mode

The Analysis Mode processes the business domain or solution domain. These models solve the design problems in modeling business processes and entity processes and the implementation methods of business transactions.

Back to Top

Tools and technology: Prototype (Archetype)

PrototypeIs a general concept and pattern that appears repeatedly in a domain or multiple domains. It can be mapped to a specific domain and used for model conversion and code generation.Party,Inventory,Purchase OrderAndMoneyThis is an example. Although similar to the analysis mode, the prototype has a higher abstraction level. The prototype can include optional functions, selection functions, or full structure variants (profiled structures) based on the business context ).

Back to Top

Tools and technologies: Representation Mode

Displays and processes operation information or events that call an application stream. The main goal of the pattern in this field is to separate specific aspects from the application and business logic. Some examples include:

• Model-View-Controller (Model-View-Controller, MVC )--This mode separates the visual representation (view) of the application model from the model itself. The Controller updates views and schedules view-level events.
• Representation-abstract-Control (Presentation-extract action-Control, PAC )--This mode is similar to MVC in many aspects and also separates functions into similar roles. Compared with MVC, PAC is more abstract and common, and may be more suitable for use outside the User Interface (UI. In some respects, this mode is related to layers, because a similar pattern can be used to design the interaction between the boundaries of each layer. A hierarchical model is another hierarchical view. Using this model as an organizational architecture principle can greatly support the "pluggable" architecture.
• Front-end controller )--The front-end controller is applicable to requests/responses. A single object is used to receive requests, schedule requests, route requests, and collect responses.
• Display Server --This mode defines an abstract service that displays information and subscribes to events. The most successful use of this mode is X Windows.

Back to Top

Tools and technology: Service-Oriented Architecture

From many perspectives, Service-Oriented Architecture (SOA) is a common influence on a group of components-based applications) the standardization of the mode set. Components Act as Service implementations, and service-related infrastructure processes decisions about connections and interactions, as described in the preceding tools and technologies: component design patterns.

Service component architecture

Service Component Architecture (SCA) is an IBM project that defines a declaration Language (XML-based, this language can be used to specify component assembly and internal and external service interface dependencies. You can use Spring to connect components together, but SCA routes the component connection function out of the distribution boundary of the implementation module. This standard is now managed by Open Service-Oriented Architecture Collaboration.

Model-Driven Architecture

Model-Driven Architecture (MDA) supports Model conversion and enrichment, and also supports mode-based local Model conversion. IBM®Rational®Software Modeler and Rational Software modelect provide support for defining patterns and directly applying them to models. ArcStyler (iO Software product) provides mature and extensive support for MDA and can be used for application mode conversion.

Back to Top

Milestone

The architect's work always involves pattern identification and application. For this reason, it is difficult to determine specific points in the project cycle to explain the progress of the model work. However, I would like to discuss some important parts of the application lifecycle here and look for and determine patterns in the application in these aspects.

Architecture

The application architecture is the main delivery content, and in most cases, the model plays an extremely important role in its development. The style of the logo architecture and other large models used in the architecture have many functions. Mode can bring the following benefits:

• Make the architecture easier to understand and describe.
• Through the known features of the model used, the major architecture decisions and advantages and disadvantages are highlighted.
• This is especially true when organizations rely on best practices as frameworks and tools to allow reuse of a large part of models and items.

Domain Model

Domain Modeling is not really new, but there is little information about how to do it. Books written by Eric EvansDomain-Driven Design(See references) provides a set of patterns for modeling domains, including techniques for identifying and determining domain boundaries and refining domain designs.

Using these techniques to record domains will greatly improve the effectiveness and durability of the application architecture.

Analysis Model

Most domains are often recognized and automated. Therefore, the domain model can fully utilize the well-designed pattern language. Please look for available modes that provide full or partial support for your domain. If this mode is not available, consider creating one. These modes should be the pattern that often repeats in the domain or standard mode (such as the money and currency modes ).

Design and Implementation

Similarly, there are many methods and time-to-use patterns in the design and implementation of application lifecycles, making it difficult to specify specific delivery content related to patterns. However, appropriate architectures based on patterns and abstractions will be easier to understand and maintain. You should be able to demonstrate under what circumstances the use mode (used in a specific region or used as the architecture Guiding Principles) handles a requirement or improves the overall quality of the architecture.

Method

In my opinion, the recommended development method is part of the application architecture. Many development modes are provided in the network and some documents. Some important examples include:

• Unified process )--An iterative phased-out development method in IBM Rational and IBM Rational Unified Process®(RUP®. RUP includes workflows and templates that can be used to configure the Basic Unified Process framework.
• RM-ODP --Reference Model for Open Distributed Processing (RM-ODP) is a modeling method of system architecture specification. The RM-ODP splits the specification and modeling of the systemViewAnd each view processes a specific set of considerations.
• Extreme Programming (XP )--XP is a lightweight method that avoids formal modeling and analysis related to the "test first" method. System requirements are captured as user cases. Convert user cases to test corresponding functions, and then write code to implement test cases. This model is most suitable for small skilled teams and is difficult to expand to large projects.
• Scrum:Another lightweight approach focuses on short-term achievements (the team submits specific deliverables for them ). It will frequently assess the progress and adjust the work investment according to the requirements of risk and demand priority.

Back to Top

Summary

The processing mode is an essential part of the architect's daily work. As I mentioned in section 1st, abstraction and modeling are two key skills. Both are related to the mode. You must be able to extract the abstract from specific needs, so as not only to form an overall overview of the architecture and its guiding principles, but also to deal with key design issues, or at a lower level of design and implementation, prepare for changes to risks.

In addition, not all content is a pattern, and not every pattern is worth recording and publishing. An inappropriate or unnecessary application model may make your design complex. Always remember the advantages and disadvantages of each pattern and evaluate the actual influencing factors that affect its usage.