. Net Architecture

. NET Official Architecture Guide

MicroServices and Docker containersweb applications with ASP.

Website address: https://www.microsoft.com/net/learn/architecture

Three-layer and multilayer architecture multitier Architecture

ASP. N-tier Architecture Schema

Visual Studio N-tier Example

Source: Https://dotnetdaily.net/featured/n-tier-architecture-asp-net

Microsoft Official N-tier Introduction: Https://docs.microsoft.com/zh-cn/visualstudio/data-tools/n-tier-data-applications-overview

Three-tier architecture Wiki

Https://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture

Https://en.wikipedia.org/wiki/Multitier_architecture

Onion Architecture Onion Architecture

Four onion architecture (Onion Architecture) principles:

• Applications are built around the standalone object model
• The inner layer defines the interface. Outer implementation Interface
• Coupling direction toward Center
• Core code for all applications can be compiled and run separately from the infrastructure

Original: http://jeffreypalermo.com/blog/onion-architecture-part-4-after-four-years/

Onion schemas are sometimes referred to as ports and adapters (Ports and adapters) schemas, or hexagonal (hexagonal) architectures. But Wade that the latter should be a superset of the onion architecture.

The core layer is a domain-or technology-independent building block of artifacts that contains common component blocks such as list, case, actor, and so on. The core layer does not contain any technical-level concepts, such as rest or databases, and so on.
The domain layer is where the business logic is defined, and the methods of each class are named according to the concepts in the domain's common language. Control of the domain layer is done through the API layer, and all business logic belongs to the domain layer. This approach ensures the portability of the application and replaces the entire technology implementation without losing any business logic.
The API layer is the portal to the domain layer, which uses terms and objects in the domain. Wade said: The API layer should only expose immutable objects to the outside world, to avoid the developer gaining access to the underlying domain through exposed objects, and arbitrarily modifying the domain behavior. Wade usually starts coding from the API layer, each of which is a skeleton and corresponds to a high-level functional test. The code logic is then added to enable the test to pass, which drives the coding implementation of the domain layer.
The infrastructure (Infrastructure) layer is the most external layer, and it contains adapters that interface with a variety of technologies, such as databases, user interfaces, and external services. It is able to access all the internal levels, but most operations are done through the API layer. However, there is an exception that is responsible for implementing some of the interfaces defined in the domain layer (e.g., interfaces for various repository).

An important concept in the onion architecture is dependency, where the outer layer is able to access the inner layer, while the inner layer knows nothing about the outer layer.

Http://www.infoq.com/cn/news/2014/11/ddd-onion-architecture

Neat Architecture Clean Architecture

Dependency rules (the Dependency rule)

Concentric circles represent different levels of software code. Usually when you think deeper about building your system, your system will be at a higher level. The outermost circle represents a mechanism-level system. The most internal representation is a policy-level system.

The most important rule is the dependency rule (the Dependency rule). This rule says: code dependencies can only be made out of the inside. In other words, the code for the inner structure cannot contain any information about the structure of the outer layer. In particular, the names of some of the outer structures should not be referred to by the inner-layer code, such as the name of the function, the class name, the variable name, or other system entity names.

Similarly, the data structure of the outer layer should not be used by the inner code, especially those generated by external frameworks. We don't want anything in the external structure to affect the internal structure.

Physical Layer (entities)

Entities are used to encapsulate business rules for a company. An entity can be an object with a method, or it can be a data structure and function. As long as the entity can be used by different business logic parts of the company, the concrete manifestation of the entity is irrelevant.

Perhaps you don't want to write a company-level architecture, but just want to write a simple application, then the entity here refers to the business logic object of the application. They encapsulate the most common rules, and when the external environment changes, these entities are the least needed to be changed. For example, these entities are the least expected to change when it comes to increasing paging requirements or security requirements. No specific application needs to change the physical layer.

User instance layer (use Cases)

The software structure of this layer contains the specific application business logic. It implements all of the user instances. The instances of these users are implemented by the flow of data flowing into the entity and the flow of data flowing out of the entity, which enables the inner entity to rely on the business logic rules defined within the entity to fulfill the user requirements of the system.

We do not want any changes in the user instance layer to affect the entity layer. We also do not want the user instance layer to be affected by changes in the external structure layer, such as the UI, the database, or any public framework. This layer should be independent of these concepts.

Of course, it must happen that the application's business logic is modified to affect the code and structure of the user instance layer. If the user's needs change, the section of this layer will of course be modified.

Interface Adaptation layer (Interface adapters)

The purpose of this layer of software architecture is to transform the data so that the data structure that facilitates the operation of user instances and entity layers becomes the most convenient data structure for external structures (such as database or Web) operations. For example, the GUI MVC structure, the expression, the view, the controller all belong to this structure. This layer is most likely to pass the data structure to the user instance layer through the controller, and return to the renderer, the view.

Data is converted at this level, which facilitates the conversion of data used by the physical layer and the user instance layer into data that can be used by the persistence layer, such as a database. This layer of code does not need to be aware of any database information. If the database is a SQL database, then all of the SQL languages should be restricted at this level, especially in the section of code that interacts with the database in this layer.

When some external services need to interact with the user instance layer and the entity layer, the data transformations that are needed at this time are rightly placed on this layer.

Frame and drive layer (frameworks and Drivers)

The outermost layer is made up of the framework and the tools used. such as databases, web frameworks and so on. Often you do not need to write a lot of code to be able to interact with the inner layer of behavior.

This layer expresses the place where all the data should be specifically finally arrived. The web is the final destination of the data, and the database is the final destination of the data. We put these things on the outermost layer, and they almost make no difference to the architecture of the whole system.

Original: https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

Translation: http://www.cnblogs.com/yjf512/archive/2012/09/10/2678313.html

DDD Domain driven tiered architecture domain-driven design four-tier architecture

1. User interface is the UI layer (or presentation layer) that is responsible for displaying information to the user and interpreting user commands. The user referred to here can be another computer system, not necessarily the person who uses the user interface.
2. Application is the application layer that defines the tasks the software needs to accomplish and directs the objects that express the domain concept to solve the problem. This level of responsibility is significant for the business and an essential channel for interacting with the application layers of other systems. The application layer is as simple as possible, does not contain business rules or knowledge, but only coordinates the tasks for the domain objects in the next layer, assigns the work, and makes them collaborate with each other. It does not reflect the state of the business situation, but it can have a different state to show the progress of a task for the user or program.
3. Domain is the domain layer (or model layer) that is responsible for expressing business concepts, business status information, and business rules. Although the technical details of preserving the business state are implemented by the infrastructure layer, the state that reflects the business situation is controlled and used by this layer. The domain layer is the core of the business software and the domain model is located at this level.
4. The infrastructure layer is the base implementation layer, providing common technical capabilities to other tiers: delivering messages to the application layer, providing persistence mechanisms for the domain layer, drawing screen components for the user interface layer, and so on. The infrastructure layer is also able to support four levels of interaction patterns through an architectural framework.

The traditional four-tier architecture is a bounded, loosely layered architecture that can be accessed at any upper level of the infrastructure layer (the "L" type), while the other layers adhere to a strict hierarchical architecture

Links: Http://www.jianshu.com/p/a775836c7e25

Software Architectureis an abstract description of the overall architecture and components of the software to guide the design of large software systems in all aspects. Not for a single language, ideas can be universal, is to achieve high-availability applications.

. Net Architecture