We continue our series in the chapter 4 about Architecture š
A. SOA ( Service Oriented Architecture )
- A.1 - The principles of Services
- A.2 - What are the Services
The technical services could be RESTful resources, SOAP interfaces, or message types. The business service emphasizes business strategy, a way to bring business and technology together. However, defining a single business service does not equate to defining a single Subdomain (2) or Bounded Context. No doubt as we perform both problem space and solution space assessments, we will find that a business service comprises a number of each.
- A.3 - SOA with Hexagonal Architecture
With the service boundary at the far left and the domain model at the heart. The basic architecture is presented in Figure 4.5, where consumers reach services using REST, SOAP, and messaging. Note that one Hexagonal-based system supports multiple technical service endpoints. This has a bearing on how DDD is used within an SOA.
B. Representational State TransferāREST
B.1 - Definition
Web protocols can be used in many different ways. Some of them match the goals of the original designers; some of them donāt. One often-used analogy highlights this using the RDBMS world familiar to many. You can use an RDBMS in line with its architectural conceptsāthat is, define tables with columns, foreign key relationships, views, constraints, and so onāor you can create a single table with two columns,one called ākey,ā one called āvalue,ā and simply store serialized objects in the value column. Of course, youād still be using an RDBMS, but many of its benefits will not be available to you (meaningful queries, joins, sorting and grouping, and so forth). In a very similar fashion, the Web protocols can be used in line with the original ideas that made them what they areāwith an architecture that conforms to the REST architectural styleāor be used in a way that fails to follow it. And similar to our RDBMS example, we ignore the underlying architectural style to our peril.
B.2 - Key Aspects of a RESTful HTTP Server
- B.2.1 - Resources
resources are a key concept. How so? As a
system designer, you decide what are the meaningful āthingsā that you want to expose as accessible from the outside, and you assign each a distinct identity. In general, each resource has one URI, and more importantly, each URI should point to one resourceāthe āthingsā you expose to the outside need to be individually addressable. For example, you might decide that each customer, each product, each product listing, each search result, and maybe each change to the product catalog should be resources in their own right. Resources have representations, renditions of their state, in one or more formats. Itās through representationsāan XML or JSON document, an HTML formās post data, or some binary formatāthat clients interact with resources.
- B.2.2 - Stateless Communication
The next key aspect is the idea of stateless communication, using self-descriptive messages. Such is an HTTP request that carries all the information the server needs to handle it. Of course, the server can (and usually will) use its own persistent state to help, but itās important that the client and server donāt rely on individual requests to set up an implicit context (a session). This enables access to each resource independently of other requests, an aspect that helps in achieving massive scalability. If you view resources as objectsāand itās not at all unreasonable to do so itās valid to ask what kind of interface they should have. The answer is another very important aspect that differentiates REST from any other architectural style for distributed systems. The set of methods that you can invoke is fixed. Every object supports the same interface. In RESTful HTTP, the methods are the HTTP verbsāmost importantly, GET, PUT, POST, DELETEāthat can be applied to resources.
- B.2.3 - Hyper-media as the Engine of Application State (HATEOAS)
Finally, a RESTful server enables a client to discover a path through the applicationās possible state transitions by means of hypermedia. This is called Hyper-media as the Engine of Application State (HATEOAS) in Fieldingās dissertation. Put more simply, the individual resources donāt stand on their own. They are connected, linked to each other. This should not come as a surprise. After all, this is where the Web got its name. For the server, this means that it will embed links in its answers, enabling the client to interact with connected resources.
B.3 - Key aspects of a RESTFull HTTP Client
A RESTful HTTP client moves from one resource to the next either by following links contained in resource representations or by being redirected to resources as a result of sending data for processing to the server. Server and client cooperate to influence the clientās distribution behavior dynamically. As a URI contains all information necessary for dereferencing an addressāincluding host name and portāa client following the hypermedia principle might end up talking to a resource hosted by a different application, a different host, or even a different company.
C. Why REST ?
a system designed conforming to REST principles fulfills the
promise of loose coupling. In general, itās very easy to add new resources and links to them in existing resource representations. Itās also easy to add support for new formats where needed, leading to a much less brittle set of system connections. A REST-based system is much easier to understand, as itās split into
smaller chunksāthe resourcesāeach of which exposes a separately testable, debuggable, and usable entry point. The design of HTTP and the maturity of the tooling with support for features such as URI rewriting and caching make RESTful HTTP a great choice for architectures that need to be both loosely coupled and highly scalable.
Owh by the way good year 2025 š!
See you next time š
Top comments (0)