SOA, REST, and hexagon architectures

SOA, REST, and hexagon architectures

Previous: "IDDD realization Domain driven Design-architecture of the classic layering"

Read the catalogue:

1. soa-Service Oriented Architecture

2. REST and restful

   1. Resource (resources)

   2. Status (state)

3. Hexagon architecture

One of the great benefits of DDD is that there is no need to use a specific architecture, and a classic layered architecture is just one, because the core domain is in the context of the bounding box, we can use a variety of styles of architecture, so we should look at the broader, interesting things are many.

We are familiar with both SOA and REST, and they are not introduced by DDD, but can be applied to DDD. Personally, I think it's best to combine the hexagonal architecture (which can also be called ports and Adapters ) to get them to work, so keep looking down.

A very important picture, excerpt from: "Implementing Domain Driven Design P111"

1. soa-Service Oriented Architecture

SOA (service-oriented Architecture), I have not used this goods, the following said that their understanding of it may not be very accurate.

Service is service, service-oriented, that is, in the SOA architecture, services are the core. Business systems are distributed in a large number of business modules, these business modules are further refined is the service, and then through the provision of service contracts published, these services are the core of SOA, service callers can be diverse, Web-side, mobile, desktop side can be, that is, it is distributed architecture, When these service callers are called, they must abide by some contracts and agreements stipulated by the publishers, and in the service itself or between the contract and agreement to be used to constrain, or the entire service set will be confused, such as the Service Release agreement to have a unified specification, can not say that a service is a specification, Services also need to be abstracted away, as much as possible reusability and so on.

Because I didn't use SOA, so some things can't be expressed, I try to understand it with another concept, that is OWIN, they may not be a domain concept, but I think some things are common, we all know OWIN architecture, there are four modules: Host, Server, Middleware and application, the most important thing between them is the component , and any one of the modules do not depend on either side of each other, this is autonomy, a module also constructs the concept of not OWIN, this is the module combination, a module of arbitrary implementation, Can all be combined into the whole OWIN, what is the reason? Because they both abide by the OWIN request processing Pipeline protocol.

Back to SOA, you will find that their concept is in fact common, summer, go out to play, walk with thirst, we are on the roadside to buy a huge coconut, and then flock to a lot of friends, they hand holding a straw, and the kind and color are different, and then your coconut filled with various habits, Looks like a hedgehog, your final end may only use a knife to cut open a hole to drink, whether it is with a straw, or use to cut open a hole, our final goal is to drink coconut juice, but the use of different tools, a coconut may be inside the juice is better to drink, outside the more difficult to drink. In this daily life example, a coconut can be seen as an SOA architecture, with small services (which can be thought of as a piece of coconut meat, which is more tasty), a variety of straws and knives to serve as service callers, and coconut skins as service agreements, Because coconut juice needs to be wrapped in coconut skin will not spill out.

SOA Architecture Principles:

• Service Encapsulation
• Service loosely coupled (loosely coupled)-the relationship between services is minimized, just knowing each other.
• Service Contract -the service acts according to the service contract defined in the service description document.
• Service Abstraction -in addition to the content described in the service contract, the service hides the logic externally.
• reusability of Services -the logic is distributed across different services to improve the reusability of services.
• the composable nature of services -a set of services that coordinate work and combine to form a composite service.
• Service Autonomy – the service has control over the encapsulated logic
• Service stateless – the service minimizes the information needed to save an activity.
• Discoverable Services -services need to provide descriptive information externally so that they can be discovered and accessed through existing discovery mechanisms.

SOA Related Materials:

• SOA in Layman's
• Http://www.baike.com/wiki/SOA
• http://zh.wikipedia.org/wiki/Service-Oriented architecture

2. REST and restful

The concept of RESTful architecture is Fielding, and Fielding is one of the main designers of the HTTP protocol. Let's look at the word restful, ful is following the noun, indicating the extent, what, for example, helpful is helpful, so we can see that the rest of the architecture can be called restful, and then we look at rest, all called " Representational state Transfer ", meaning" the transformation of the presentation layer ".

In accordance with the principle of architecture, understanding and evaluating the architecture design of network-based application software, a powerful, good performance, suitable for communication architecture. -fielding

This is what Fielding mentioned in his paper, for REST is architecture, but if you go deeper, like an HTTP protocol, you can look at a rule or protocol. We can travel from one location to another, by car, high-speed rail, plane, etc., for rest is like one of the modes of transportation, but rest is the HTTP protocol, that is, rest is based on the HTTP protocol, which is like riding a car must have a road, high-speed rail must have a railroad is the same reason , sometimes why REST, like we from Nanjing to Xuzhou, choose to take the high-speed rail and not choose to fly.

"Representational state Transfer" We break down:

• Representational Presentation Layer : The expression layer shows what, should be present resources, a picture, a paragraph of text, a file is a resource, each resource is a URI (Uniform Resource Locator) point to it, the presentation layer is called URI The resources are presented, and only rendered, not other operations. For example, the last ". html" suffix of some URLs is unnecessary, because the suffix name represents the format, which belongs to the "presentation layer" category, and the URI should only represent the location of the "resource". Its specific representation should be specified in the header information of the HTTP request with the Accept and Content-type fields, which is the description of the "presentation layer".
• State Transfer Status Conversion : Access to a site, the client and the server has an interaction behavior, in this process, there is no data and state conversion, the above mentioned that the HTTP protocol is stateless, if the client Operation server, must state conversion, This is reflected in the expression layer, so called "expression layer State transformation."

Through the above understanding, you can summarize what is a RESTful architecture:

• Each URI represents a single resource.
• Between the client and the server, some kind of presentation layer that passes this resource.
• The client operates on server-side resources through four HTTP verbs (PUT, GET, POST, and DELETE), enabling "presentation State transformation."

The rest and restful concepts above are excerpted from a long-ago blog post: An initial initial ASP. NET Web Api/mvc API (with demo), with some modifications.

I'm going to take another look at what I'm now understanding, first of all, rest is an architectural style, not an architecture, an architectural style can be implemented in a variety of architectures, and one architecture may contain multiple architectural styles, the relationship between which you can understand as abstractions and implementations, and rest strictly, should belong to An architectural style of the WEB architecture, because it is inseparable from the HTTP protocol.

Two keys to the REST architecture style:

2.1 Resource (resources)

The expression of a Web resource is a URI, a canonical URI is an open resource, it is unique and has a certain specification, the operation of the resource is the method provided by HTTP (PUT, GET, POST and DELETE), the expression of resources is diverse, such as: JSON, XML , YAML, and so on.

Let's look at the commonly used URIs:

• Get:cnblogs.com/getuser/1
• Post:cnblogs.com/createuser
• Put:cnblogs.com/updateuser/1
• Delete:cnblogs.com/deleteuser/1

Obviously, this URI does not conform to the REST's definition of the resource, and we try to modify it:

• Get:cnblogs.com/user/1
• Post:cnblogs.com/user
• Put:cnblogs.com/user/1
• Delete:cnblogs.com/user/1

cnblogs.com/user/1, the general meaning of this URI is: Id 1 of the User resource, this is simply a statement, the URI does not contain any operations on this resource, so, such as GetUser, createUser such operations are not appropriate, the operation of the resource is provided through HTTP methods, and one thing is, such as cnblogs.com/user cnblogs.com/user/1 What is the difference in POST? The first post, typically creating a new user resource, is typically returned with a URI like this: cnblogs.com/user/1 the second post, instead of creating a user resource with ID 1, creates a resource under the user resource with ID 1, and you'll find that good The URI design should not contain verbs.

2.2 Status (state)

First of all, REST is stateless (statelessness), I have not understood the meaning of the state before, it seems that the state and the resource format (XML, JSON) Confused, it is really absurd to think about the state of a few points:

• The state is divided into: the Application state (application states) and the resource status (Resource state).
• Application Status: Status information related to a particular request.
• Resource status: Reflects a particular state of a stored server-side resource at a certain point in time.
• The client is responsible for maintaining the application state, while the service side maintains the resource state.
• The server side does not maintain any resources related to a particular HTTP request.

The stateless in REST actually refers to the application state, the stateless performance is the service side does not save the application state, that is, the client initiates the state related to the request, the application state is provided by the client when initiating the request, what does the state transformation mean? In fact, refers to the service side of the state of the transformation of resources, expressed in the client, that is, "performance state transformation" above.

In the ASP. NET application, we all know the concept of the session, that is, the conversation, that is, about the user request of the session, should be divided into the application state, the session state is stored on the server side, from this point of the design is unrestful style, REST of the stateless, is a concept expressed in client and server-side interactions, sometimes, although the application state may not be guaranteed to exist on the server side, but the client initiated some requests that the meaning of the expression is not appropriate, can also be considered to be non-RESTful style, such as client-initiated requests include Session ID, on the server side, The client initiated this request, the meaning is to get a session, in particular, the conversation state is saved on the server, although this is only a concept of client request, but can also think that this design is unrestful style.

In general, architectural style is not a specific architecture, it is a style.

REST Reference:

• REST
• In Layman's Rest
• Understanding the RESTful architecture
• Stateless, REST, restful, and Web Services
• A little understanding of statelessness in rest

3. Hexagon Architecture

The above-mentioned SOA, REST narration, without the slightest shadow of DDD, they are not for DDD, you can use them in architecture design, but for the overall DDD architecture design, there is always something wrong, this time, you need to understand the next hexagon structure.

Hexagon Architecture (hexagonal Architecture), also known as the port and adapter architecture style, where the "six" specific numbers do not have a special meaning, only a "magnitude" meaning, hexagonal definition is only convenient for more image understanding.

We know that the important role of layered architecture is to avoid the emergence of coupling, the classic layered architecture and hexagon architecture is one of the layered architecture, but the role will be somewhat different, the classic layered architecture more focus on the separation of abstraction, each layer of responsibility is clear, the dependencies of each layer is more abstract, In order to avoid the appearance of coupling, and in the hexagonal architecture, the "modular" form to avoid the appearance of coupling, each business unit as small as possible, and then put together these business components, with a hammer to beat them all, so, throughout the collection, these small business units are "equal", This approach is summed up in one word, which is " flattening ".

At the beginning of the blog post, I said this: because the core domain is in the bounding context, we can use multiple styles of architecture.

So why is the core domain in the context of the gauge, DDD can use a variety of styles of architecture? Let us analyze that the core domain refers to the core business logic in the business system, which is usually expressed in common language, which is a boundary that wraps around the core domain, that is, the core domain is not a component representation, and you can think of it as an aggregation concept, bounded by the bounds context, This concept is described in the previous blog post. The core domain is undoubtedly the core concept for a business system, and the focus of DDD is it, and developers and domain experts spend a lot of time exploring it, but for architectural design, the core domain is just a business focus, not a core point in architecture design, so it can be said, DDD and architecture design, In fact, strictly speaking, it should be the concept of two areas, their combination really constitute the overall business system, in other words, the most rotten architecture design with the best DDD (business), this is also possible, because DDD is focused on business implementation, not technology implementation.

We know that the classic layered architecture is divided into four tiers, whereas for hexagon architectures, it is generally divided into three layers:

• domain Layer : the innermost, purely core business logic, generally does not contain any technical implementations or references.
• Port layer (Ports layer): Outside the domain layer, is responsible for receiving all requests related to use cases, which are responsible for coordinating work in the domain layer. The port layer acts as the boundary of the domain layer inside the port, and outside the port plays the role of the external entity.
• Adapter Layer (adapters layer): Outside the port layer, responsible for receiving input in some format, and generating output. For example, for an HTTP user request, the adapter translates to a call to the realm layer and marshals the response from the realm layer back to the calling client over HTTP. There is no domain logic at the adapter layer, its sole responsibility is to make a technical transition between the outside world and the domain layer. The adapter can be associated with a port protocol and use that port, and multiple adapters may use the same port, allowing the new interface to use the same port as the old interface when switching to a new user interface.

In the hexagon structure, the domain layer and the technology does not have a semi-gross money relationship, can be seen as the technical implementation of the business, the port layer is wrapped in the domain layer outside, the external to and the domain layer of "communication", you must pass the port layer of "nod", in turn, the domain layer outward "communication" is the same, For example, the management of domain objects:

Domain layer want to get a domain object, to carry out the business operation implementation, and then told the port layer said: "Port brother, brother needs a XXX domain Model, immediately to call people to engage!" ", the port brother thought, the eldest brother said, must hurriedly ah, and then on his chest, posted such a notice: can catch XXX Domain Model adapter killer, please speed to me here, there will be rewarded! Notice a posted, adapter killers flocked, and then according to their ability to judge, after all, XXX Domain Model is not so easy to grab, nor a random adapter killer can be done, which requires a certain ability, finally can do the adapter killer to expose this notice.

The above is an impromptu thought of a plot, in fact, is a hexagonal structure, from the inside to outside a process of reflection, in turn, from the adapter layer to the domain layer is the same, this way is generally accepted user request processing started. In fact, in a sense, the port layer is a bit like the application layer, but the application layer after the beat , and the adapter layer is a bit like the infrastructure layer, but the all - around infrastructure layer, hexagon is a circular structure, so the expression of more image.

Another point is that the presence of the port layer is also conducive to the conduct of the test, these tests are not carried out in the domain layer, so it does not affect the progress of the domain layer, the test of the port layer is generally the test domain layer of business correctness.

These are some of the concepts of the hexagon architecture, and how do we combine SOA with REST? Because in the hexagon architecture, the adapter layer is the component nature of the service provided, he and the domain layer to connect through the port layer, this port layer can be regarded as a service protocol or specification, this is the use of SOA and REST, to play the role of the adapter layer and the port layer. Another concept is that the service interaction is divided into the service side and the client, for SOA and REST itself, their implementation is the service side, but in the hexagonal architecture, they are more like a client, and the expression is a component of the service, and the domain layer is the service side, The component service is invoked through the port Protocol to provide some operational implementations.

The combination of SOA, REST, and hexagon architectures can be compared to the first diagram:

Description: This image is excerpted from: "Implementing Domain Driven Design P115"

Resources:

• Hexagonal architecture
• Explore Hexagon Architecture
• Visual Architecture and DDD
• SOA distributed software architecture with domain-driven design

The distance from the previous article for a long time, the classic layered architecture I used, so there will be a lot of feelings, there are a lot of words to express, but for the SOA, REST and hexagon architecture, I have not really used, so, for a concept you have not touched, it is difficult to write something out, Can't write, then read books, read articles, find information, some have feelings of writing down, and then through their own understanding to express, this way process although very slow, but still have a certain effect.

There are a lot of things about DDD architecture design, such as CQRS, event-driven architecture, GRID-distributed computing, and so on, which takes time to digest.

Because there is no practice, so inevitably there will be some problems, but also please treatise!!!

SOA, REST, and hexagon architectures