Implementing Domain Driven Design - Day 7

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.

Credits:IDDD of Vernon

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 😁