DEV Community

Cover image for Implementing Domain Driven Design - Day 7
DevByJESUS
DevByJESUS

Posted on

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

services_principles

  • 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.

soa_and_hexagonal
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 šŸ˜

šŸ’” One last tip before you go

Tired of spending so much on your side projects? šŸ˜’

We have created a membership program that helps cap your costs so you can build and experiment for less. And we currently have early-bird pricing which makes it an even better value! šŸ„

Check out DEV++

Top comments (0)

A Workflow Copilot. Tailored to You.

Pieces.app image

Our desktop app, with its intelligent copilot, streamlines coding by generating snippets, extracting code from screenshots, and accelerating problem-solving.

Read the docs

šŸ‘‹ Kindness is contagious

Dive into an ocean of knowledge with this thought-provoking post, revered deeply within the supportive DEV Community. Developers of all levels are welcome to join and enhance our collective intelligence.

Saying a simple "thank you" can brighten someone's day. Share your gratitude in the comments below!

On DEV, sharing ideas eases our path and fortifies our community connections. Found this helpful? Sending a quick thanks to the author can be profoundly valued.

Okay