Introduction to Software Architecture

This article describes the architecture of the software What is a software architecture and why do we need it? Just like other complex structures, software must be built on a solid foundation. Without a critical scenario in mind, no design for common problems, or long-term results without taking into account important decisions, you put your software application at risk. The code has no schema, just like the Ivy in the garden, it becomes difficult to maintain, and it is difficult to add new features. Software architecture is a technical blueprint that explains how systems are built by subsystems (modules) when it comes to optimizing common properties such as software performance, security, and manageability. Philippe Kruchten, Grady Booch, Kurt Bittner and Rich Reitman extended and refined the results of Mary Shaw and David Garlan (Shaw and Garlan 1996) Definition of software architecture. They are defined as: The software architecture contains a number of important decisions about the organizational structure of a software system, including how to select the structure elements and structures of the system, the specific behavior of those elements collaborating, and how these structures and behavioral elements form a larger subsystem, and the architectural style that guides this organizational structure. The software architecture also includes functionality, usability, applicability, software performance, reusability, economic and technical constraints, tradeoffs, and aesthetics.

In Patterns of Enterprise application Architecture  , M Artin Fowler summarizes some of the topics that are often mentioned in the explanatory architecture. He considers these topics to be: A system that breaks down into multiple parts at the highest level; A system can have multiple schemas, and clearly structured things will change in the life cycle of a system; Finally, the architecture boils down to anything important. In the   software Architecture in Practice (2nd edition) , the Bass, Clements, and Kazman define the schema: The software architecture of a program or computer system refers to a structure or multiple structures of systems that compose software elements, external visibility of elements, and relationships between elements. The architecture cares about the public interface; The private details of the element--the details of the internal implementation--are not schemas. The goal of the Schema is to identify the requirements that affect the application structure. A good architecture can reduce the business risk of building a technology solution. Excellent design is flexible enough to handle changing hardware and software technologies, as well as user scenarios and requirements.

Software architecture provides some benefits, including: higher productivity. The   structure makes it easier to add new personalities to existing software, and the location of each new code is known in advance. better code maintainability.   Code structures are visible and known, which makes it easier to maintain existing software and makes it easier to find bugs and anomalies. higher adaptability.   Software architectures with a clear separation in mind, it is easier to accomplish new technology features such as changing a front end and adding a business rule engine. promotes agnosticism.   Finally, but not necessarily, the software architecture allows you to see what is advertised and fashionable in the industry based on your current structure, adapting to these hype and trendy things. Software architecture patterns and styles client/server-side Architecture The client/server side is a two-part software architecture model that communicates with the client system and server-side systems over a computer network-or on the same computer. A client-server application is a distributed system consisting of a client and a server-side software. Client-server applications provide a good way to offload load. The client process always initiates a connection to the server, and the server process always waits for requests from any client. The client-server architecture is sometimes also an angle-Austrian two-tier architecture.

component-based architecture Component-based architecture focuses on design decomposition, which is designed as a separate functional or logical component to represent a well-defined communication interface that contains methods, events, and properties. It provides a higher level of abstraction and decomposes the problem into component-related sub-problems. The primary purpose of the Component-based architecture is to ensure the reusability of components. Component encapsulates the functionality and behavior of a software element into a reusable, standalone deployment executable unit. The following are two components represented in UML 2.0. The checkout component responsible for processing user orders needs to be deducted from the user's credit/debit card via the Cardprocessing component (i.e. the functionality provided by the latter). domain driven design Domain driven design (DDD) is a way to create high-quality software that meets the core business goals. It emphasizes collaboration among domain experts, developers, UX designers, and other stakeholders to create a domain model that reflects the business needs. This includes the negotiation of generic terms (also known as common language), the designation of business entities and their behavior and relationships, and is organized in a way that generates neat and modular implementations. Policy domains drive design patterns and their relationships

Hierarchical schema The hierarchical architecture focuses on combining related functions in an application into different levels, with layers showing vertical cascading structures. The functionality in each layer is associated with a common and role or responsibility. Communication between the tiers is clear and loosely coupled. A hierarchy of your applications can be very helpful in supporting the separation of concerns policy, which in turn supports flexibility and maintainability. The Message bus schema Message bus schema describes a principle that describes a software system that can be used to receive and send messages using one or more communication channels, so that the application can interact without knowing the specific details of each channel. This is a style of designing an application in which the interaction between applications is accomplished by the passing of the message on the common bus (which is often asynchronous). The most common implementation of the message bus architecture is not the use of message routing, which is the Publish/subscribe pattern, and is often implemented using a message system such as Message Queuing. N-tier/3-tier Architecture N-tier/3-tier Architecture description is a layer that separates functionality roughly like a layered style of architecture, and makes each section a tier that can be placed on a physically separate computer. They are developed through a component-oriented approach, and general communication is a platform-specific approach, rather than a message-based way.

Object-Oriented Architecture Object-oriented architecture is a design paradigm based on responsibility decomposition, which decomposes the system into independent reusable objects, each of which contains data and behavior related to itself. Object-oriented design sees the system as a series of mutually collaborative objects rather than a set of programs or processing instructions. Objects are separated from each other, independent and loosely coupled; they call or process properties within other objects through an interface and communicate on the interface through the sending and receiving of messages. Service-Oriented Architecture (SOA) A service-oriented architecture (SOA) is a way to create an architecture that is based on the use of services. Services, such as RESTful Web Service, implement a number of small functions, such as generating data, validating users, or providing simple Analysis Services. The key to SOA architecture is the interaction between independent and loosely coupled services. The SOA architecture enables the reuse of services, so there is no need to start from scratch when upgrading or other changes need to be made.

Onion structure The onion architecture is proposed by Jeffrey Palermo, which resembles the hexagonal architecture proposed by the Alistair Cockburn (hexagonal Architecture). The architecture was originally proposed to avoid dependencies between tiers in an N-tier architecture. It is implemented by moving all underlying services, including databases, out of the problem domain. Implementing this theory to an N-tier architecture means reversing the dependency stream, thereby independently of the business logic. This theory creates a new model in which the business logic is at the center of the architecture, and the other layers surround it with concentric rings, just like an onion.

Original address: Http://www.oschina.net/translate/introduction-to-software-architecture

Introduction to Software Architecture