DEV Community: DevByJESUS

Implementing Domain Driven Design - Services

DevByJESUS — Tue, 15 Jul 2025 08:08:29 +0000

We continue our series in the chapter 7 of IDDD which talks about Services 😁

A. The problem ⚠️

In the blue book, it says :

There are important domain operations that can't find a natural home in an ENTITY or VALUE OBJECT. Some of these are intrinsically activities or actions, not things, but since our modeling paradigm is objects, we try to fit them into objects anyway. Now, the more common mistake is to give up too easily on fitting the behavior into an appropriate object, gradually slipping toward procedural programming. But when we force an operation into an object that doesn't fit the object's definition, the object loses its conceptual clarity and becomes hard to understand or refactor. Complex operations can easily swamp a simple object, obscuring its role. And because these operations often draw together many domain objects, coordinating them and putting them into action, the added responsibility will create dependencies on all those objects, tangling concepts that could be understood independently.

So here is the problem, we have some operations but they can not be put inside an Entity or a Value Objects , how to deal with those operations ?

B. The Solution 🤔

The solution is to create some doers, and the book says :

Sometimes services masquerade as model objects, appearing as objects with no meaning beyond doing some operation. These "doers" end up with names ending in "Manager" and the like. They have no state of their own nor any meaning in the domain beyond the operation they host. Still, at
least this solution gives these distinct behaviors a home without messing up a real model object.

C. Service 😌

Before giving the definition of the book i want to emphasize the fact that this term is proper to DDD and is not equal to the way we put a suffix to some classes in our java or typescript projects for example, it is a conceptual thing :

In the blue book :

A SERVICE is an operation offered as an interface that stands alone in the model, without encapsulating state, as ENTITIES and VALUE OBJECTS do. SERVICES are a common pattern in technical frameworks, but they can also apply in the domain layer.

In the red book :

A Service in the domain is a stateless operation that fulfills a domain-specific task. Often the best indication that you should create a Service in the domain model is when the operation you need to perform feels out of place as a method on an Aggregate or a Value Object.

D. Domain Service is not an Application Service 🤨

Because when we see the big picture of domain driven design the line between the application and the domain is thin, and so the concept of service is different between the two :

Don’t confuse a Domain Service with an Application Service. We
don’t want to house business logic in an Application Service, but we do want business logic housed in a Domain Service. Briefly, to differentiate the two, an Application Service, being the natural client of the domain model, would normally be the client of a Domain Service.

N.B : For example in a banking application, if the banking application can convert and export our transactions into a spreadsheet file for us to analyze, that export is an application SERVICE. There is no meaning of "file formats" in the domain of banking, and there are no business rules involved. On the other hand, a feature that can transfer funds from one account to another is a domain SERVICE because it embeds significant business rules (crediting and debiting the appropriate accounts, for example) and because a "funds transfer" is a meaningful banking term.

E. GOOD Domain Service

There is three characteristics :

The operation relates to a domain concept that is not a natural part of an ENTITY or VALUE OBJECT.
The interface is defined in terms of other elements of the domain model.
The operation is stateless.

N.B : Statelessness here means that any client can use any instance of a particular SERVICE without regard to the instance's individual history. The execution of a SERVICE will use information that is accessible globally, and may even change that global information (that is, it may have side effects). But the SERVICE does not hold state of its own that affects its own behavior, as most domain objects do.

F. Repartition of services 💭

In this picture you can see where each service belongs to :

Conclusion : To conclude we can say , SERVICE, the pattern is also valuable as a means of controlling granularity in the interfaces of the
domain layer, as well as decoupling clients from the ENTITIES and VALUE OBJECTS. Medium-grained, stateless SERVICES can be easier to reuse in large systems because they encapsulate significant functionality behind a simple interface. Also, fine-grained objects can lead to inefficient messaging in a distributed system.

See you next time 😁

Implementing Domain Driven Design - Value Objects

DevByJESUS — Wed, 09 Jul 2025 08:37:27 +0000

We continue our series in the chapter 6 about Value Objects 😁

A. Problem 🤔

Tracking the identity of ENTITIES is essential, but attaching identity to other objects can hurt system performance, add analytical work, and muddle the model by making all objects look the same. Software design is a constant battle with complexity. We must make distinctions so that special handling is applied only where necessary. However, if we think of this category of object as just the absence of identity, wehaven't added much to our toolbox or vocabulary. In fact, these objects have characteristics of their own and their own significance to the model. These are the objects that describe things.

B. Definition 🔑

An object that represents a descriptive aspect of the domain with no conceptual identity is called a VALUE OBJECT. VALUE OBJECTS are instantiated to represent elements of the design that we care about only for what they are, not who or which they are.

C. Value Objects Characteristics 📕

1️⃣ Measures, Quantifies, or Describes

When you have a true Value Object in your model, whether you realize it or not, it is not a thing in your domain. Instead, it is actually a concept that measures, quantifies, or otherwise describes a thing in the domain. A person has an age.The age is not really a thing but measures or quantifies the number of years the person (thing) has lived. A person has a name. The name is not a thing but describes what the person (thing) is called.

2️⃣ Immutable

An object that is a Value is unchangeable after it has been created. Instantiation of a value objects class alone does not guarantee that an object is immutable. After the object has been instantiated and initialized by means of construction, none of its methods, whether public or hidden, will from that time forward cause its state to change.

3️⃣ Conceptual Whole

You can see the full explanation of the WholeValue. But the point is simply A Value Object may possess just one, a few, or a number of individual attributes,
each of which is related to the others. Each attribute contributes an
important part to a whole that collectively the attributes describe. Taken apart from the others, each of the attributes fails to provide a cohesive meaning. Only together do all the attributes form the complete intended measure or description.

4️⃣ Value Equality

When a Value Object instance is compared to another instance, a test of object equality is employed. Throughout the system there may be many, many Value instances that are equal, and yet not the same objects. Equality is determined by comparing the types of both objects and then their attributes. If both the types and their attributes are equal, the Values are considered equal.

5️⃣ Replaceability

In your model an immutable Value should be held as a reference by an Entity as long as its constant state describes the currently correct Whole Value. If that is no longer true, the entire Value is completely replaced with a new Value that does represent the currently correct whole. Because two value objects are equals if all the attributes are same, so a value object can replace another if it has the same value for the attributes

6️⃣ Side-Effect-free Function

A method of an object can be designed as a Side-Effect-Free Function [Evans]. A function is an operation of an object that produces output but without modifying its own state. Since no modification occurs when executing a specific operation, that operation is said to be side-effect free. The methods of an immutable Value Object must all be Side-Effect-Free Functions because they must not violate its immutability quality.

Conclusion : Whether to treat a concept as a reference object or value object depends on your context. In many situations it's worth treating a postal address as a simple structure of text with value equality. But a more sophisticated mapping system might link postal addresses into a sophisticated hierarchic model where references make more sense. As with most modeling problems, different contexts lead to different solutions. It's often a good idea to replace common primitives, such as strings, with appropriate value objects. While I can represent a telephone number as a string, turning into a telephone number object makes variables and parameters more explicit (with type checking when the language supports it), a natural focus for validation, and avoiding inapplicable behaviors (such as doing arithmetic on integer id numbers).

See you next time 😁

Implementing Domain Driven Design - Entities

DevByJESUS — Tue, 01 Jul 2025 09:45:33 +0000

We continue our series in the chapter 5 about Entities 😁

A. The problem

Here is the problem, our entities do not reflect the importance of

Instead of designing domain concepts with rich behaviors, we might think primarily about the attributes (columns) and associations (foreign keys) of the data. Doing so reflects the data model into object counterparts, which leads to almost every concept in our “domain model” being coded as an Entity abounding with getter and setter methods.

here is the problem, we have entities we only getters and setters and no domain logic!

B. What is a true Entity

We design a domain concept as an Entity when we care about its individuality, when distinguishing it from all other objects in a system is a mandatory constraint. An Entity is a unique thing and is capable of being changed continuously over a long period of time. Changes may be so extensive that the object might seem much different from what it once was. Yet, it is the same object by identity.

It is the unique identity and mutability characteristics that set Entities apart from Value Objects

C. When a CRUD is enough 🙃

There are times when an Entity is not the appropriate modeling tool to
reach for. Misappropriated use happens far more often than many are aware. Often a concept should be modeled as a Value. If this is a disagreeable notion, it might be that DDD doesn’t fit your business needs. It is quite possible that a CRUD-based system would be more fitting. When CRUD makes sense, languages and frameworks such as Groovy and Grails, Ruby on Rails, and the like make the most sense. If the choice is correct, it should save time and money.

D. When DDD is necessary😉

When complexity grows, we experience the limitation of poor tool selection. CRUD systems can’t produce a refined business model by only capturing data. If DDD is a justifiable investment in the business’s bottom line, we use Entities as intended.

And if we talk about the fact to track changes of an entity, that entity has to have a unique identifier , and Eric Evans says :

When an object is distinguished by its identity, rather than its attributes, make this primary to its definition in the model. Keep the class definition simple and focused on life cycle continuity and identity. Define a means of distinguishing each object regardless of its form or history. The model must define what it means to be the same thing

E. Unique Identity for an Entity

So that’s what we’ll do first. Having a range of available options for implementing identity is really important, as are those for ensuring that the uniqueness is preserved throughout time.

We will go through each of the method for ensuring unique identity for an entity

1️⃣ User provides identity

Let's see in details :

✅ Advantage(s): It appears to be a straightforward approach to have a user manually enter the details of unique identity. The user types a recognizable value or symbol into an input field or selects from a set of available characteristics, and the Entity is created.

❌ Disadvantage(s): One complication is relying on users to produce quality identities. The identity may be unique but incorrect. Most times identities must be immutable, so users shouldn’t change them. Can users be relied upon to produce both unique and correct, long-lasting identities?

2️⃣ Application generates identity

In details

✅ Advantage(s): There are highly reliable ways to autogenerate unique identities, although care must be taken when the application is clustered or otherwise distributed across multiple computing nodes. There are identity creation patterns that can, to a much greater degree of certainty, produce a completely unique identity. The universally unique identifier (UUID), or globally unique identifier (GUID).

❌ Disadvantage(s): the identity is big and is not considered human-readable.

3️⃣ Persistence Mechanism Generates Identity

✅ Advantage(s): Delegating the generation of unique identity to a persistence mechanism has some unique advantages. If we call on the database for a sequence or incrementing value, it will always be unique. Depending on the range needed, the database can generate a unique 2-byte, 4-byte, or 8-byte value. In Java, a 2-byte short integer would allow for up to 32,767 unique identities; a 4-byte normal integer would afford 2,147,483,647 unique values; and an 8-byte long integer would provide up to 9,223,372,036,854,775,807 distinct identities. Even zero-filled text representations of these ranges are narrow, at five, ten, and 19 characters respectively.

❌ Disadvantage(s): One possible downside is performance. It can take significantly longer to go to the database to get each value than to generate identities in the application. Much depends on database load and application demand. One way around this is to cache sequence/increment values in the application, such as in a Repository.

4️⃣ Another Bounded Context assigns Identity

✅ Advantage(s) : When another Bounded Context assigns identity, we need to integrate to find, match, and assign each identity. DDD integrations are explained in Context Maps and Integrating Bounded Contexts. Making an exact match is the most desirable. Users need to provide one or more attributes, such as an account number, username, e-mail address, or other unique symbol, to pinpoint the intended result.

❌ Disadvantage(s): This has synchronization implications. What happens if externally referenced objects transition in ways that affect local Entities? How will we know that the associated object changed?

💡 solution(s): This problem can be solved using an Event-Driven Architecture with Domain Events. Our local Bounded Context
subscribes to Domain Events published by external systems. When a relevant notification is received, our local system transitions its own Aggregate Entities to reflect the state of those in external systems.

Conclusion : An Entity is an object that has a unique identity that runs through time and different states. Is mutable — its attributes may change, but it remains the same entity. Is distinguished by its ID rather than its attributes.

See you next time 😁

Patterns of Enterprise Application Architecture - Data Source Patterns (3)

DevByJESUS — Mon, 30 Jun 2025 08:12:55 +0000

Today we end that chapter , with the Data Mapper pattern

A. The problem

Objects and relational databases have different mechanisms for structuring data. Many parts of an object, such as collections and inheritance, aren’t present in relational databases. When you build an object model with a lot of business logic it’s valuable to use these mechanisms to better organize the data and the behavior that goes with it. Doing so leads to variant schemas; that is, the object schema and the relational schema don’t match up. You still need to transfer data between the two schemas, and this data transfer becomes a complexity in its own right. If the in-memory objects know about the relational database structure, changes in one tend to ripple to the other.

How to make the object schema and the relational schema work together in a cohesive way ?

B. The Solution

The Data Mapper is a layer of software that separates the in-memory objects from the database. Its responsibility is to transfer data between the two and also to isolate them from each other. With Data Mapper the in-memory objects needn’t know even that there’s a database present; they need no SQL interface code, and certainly no knowledge of the database schema.

C. How it works ?

The way it works, we have to deal with two important steps :

1 - Finder : The step of finding is an important step, it goes from the presentation layer to the domain layer, and the domain object after going from object to objects , makes the request to the mapper layer.

2 - Mapping Data to Domain Fields : Once the mapper has retrieved the response from the database , we have to find a way to map the column from the database to the domain fields. The first solution is to have Rich Constructor it’s nice to have a well-formed object from the start. This also means that, if you have an immutable field, you can enforce it by not providing any method to change its value. The second is to use a no args constructor the point here is to create an empty object and then populate it with the mandatory data.

Here we have a figure to show the sequential order :

D. When to use it ?

To say it simply :

The primary occasion for using Data Mapper is when you want the database schema and the object model to evolve independently. The most common case for this is with a Domain Model. Data Mapper’s primary benefit is that when working on the domain model you can ignore the database, both in design and in the build and testing process. The domain objects have no idea what the database structure is, because all the correspondence is done by the mappers.

And how can i test that :

So the test for using these patterns is the complexity of the business logic. More complicated logic leads you to Domain Model and therefore to Data Mapper.

Conclusion: Here we do not have the coupling between the domain and the datasource, the data mapper for me is a good layer for low coupling

Patterns of Enterprise Application Architecture - Data Source Patterns (2)

DevByJESUS — Mon, 23 Jun 2025 08:19:18 +0000

Today we will dive in the Active Record data source patterns for enterprise applications

A. Active Record

A.1 Definition

An object carries both data and behavior. Much of this data is persistent and needs to be stored in a database. Active Record uses the most obvious approach, putting data access logic in the domain object. This way all people know how to read and write their data to and from the database.

A.2 How it works ?

Each Active Record is responsible for saving and loading to the database and also for anyndomain logic that acts on the data. This may be all the domain logic in the application, or you may find that some domain logic is held in Transaction Scripts with common and data-oriented code in the Active Record.The data structure of the Active Record should exactly match that of the database: one field in the class for each column in the table. Type the fields the way the SQL interface gives you the data—don’t do any conversion at this stage.

A.3 Composition of an Active Record Class

The Active Record class typically has methods that do the following:

• Construct an instance of the Active Record from a SQL result set row

• Construct a new instance for later insertion into the table

• Static finder methods to wrap commonly used SQL queries and return
Active Record objects

• Update the database and insert into it the data in the Active Record

• Get and set the fields

• Implement some pieces of business logic

A.4 When to use it ?

The author of the book says :

Active Record is a good choice for domain logic that isn’t too complex, such as creates, reads, updates, and deletes. Derivations and validations based on a single record work well in this structure.

Active Record is a good pattern to consider if you’re using Transaction Script and are beginning to feel the pain of code duplication and the difficulty in updating scripts and tables that Transaction Script (110) often brings. In this case you can gradually start creating Active Records and then slowly refactor behavior into them.

A.5 What's in the Real World

In the real world we have ActiveRecord (Ruby on Rails), Eloquent (Laravel / PHP), some implementations of JPA (Java Persistence API), Django ORM (Python)

When you use those ORM you'll face Active Record pattern because in each the class contains the domain information and can do the operations directly againts the database

Conclusion : The problem is the coupling between the domain and the database, and that's why the next time , we will talk about Data mapper 😉

Patterns of Enterprise Application Architecture - Data Source Patterns (1)

DevByJESUS — Thu, 19 Jun 2025 08:42:39 +0000

Today we will dive in some of the data source patterns for enterprise applications

A. Table Data Gateway

A Table Data Gateway holds all the SQL for accessing a single table or view: selects, inserts, updates, and deletes. Other code calls its methods for all interaction with the database.

A.1 How it works ?

A.1.1 Insertion Part

A Table Data Gateway has a simple interface, usually consisting of several find methods to get data from the database and update, insert, and delete methods. Each method maps the input parameters into a SQL call and executes the SQL against a database connection.The Table Data Gateway is usually stateless, as its role is to push data back and forth.

A.1.2 Retrieving Part

Here we have a problem with that patterm because, it will return multiple items even for a simple findById(id) method !
We have alternatives for that :

-Map: A map works, but it forces data to be copied out of the record set that comes from the database into the map. But the problem with a Map is that it can not be used everywhere !

-DTO: However a DTO can, yes we have to create another object but a DTO can be used or processed but much more environments

A.2 When to use it ?

According to the author :

I find that Table Data Gateway is probably the simplest database interface pattern to use, as it maps so nicely onto a database table or record type. It also makes a natural point to encapsulate the precise access logic of the data source. Table Data Gateway works particularly well with Table Module, where it produces a record set data structure for it.

B. Row Data Gateway

If it is not white, it's dark 😂

A Row Data Gateway gives you objects that look exactly like the record in your record structure but can be accessed with the regular mechanisms of your programming language. All details of data source access are hidden behind this interface.

B.1 How it works ?

B.1.1 Behind the hood

A Row Data Gateway acts as an object that exactly mimics a single record, such as one database row. In it each column in the database becomes one field. The Row Data Gateway will usually do any type conversion from the data source types to the in-memory types, but this conversion is pretty simple. This pattern holds the data about a row so that a client can then access the Row Data Gateway directly

But we have the problem of how to generate a Row data gateway ?

B.1.2 Creating a Row Data Gateway

With a Row Data Gateway you’re faced with the questions of where to put
the find operations that generate this pattern. You can use static find methods, but they preclude polymorphism should you want to substitute different finder methods for different data sources. In this case it often makes sense to have separate finder objects so that each table in a relational database will have one finder class and one gateway class for the results

Like you see in the image below, we create a Finder that will generate for us Row data gateway for the Person model

B.2 When to use it ?

I use Row Data Gateway most often when I’m using a Transaction Script . In this case it nicely factors out the database access code and allows it to be reused easily by different Transaction Scripts. A Row Data Gateway
should contain only database access logic and no domain logic.

Conclusion : The choice of Row Data Gateway often takes two steps: first whether to use a gateway at all and second whether to use Row Data Gateway or Table Data Gateway. 😉

Implementing Domain Driven Design - Event Driven Architecture

DevByJESUS — Fri, 13 Jun 2025 09:07:42 +0000

We continue our series in the chapter 4 about Architecture 😁
Today we will talk about Event Driven Architecture ( EDA )

A. Definition

In a simple way :

Event-driven architecture (EDA) is a software architecture promoting the production, detection, consumption of, and reaction to events.

B. What kind of events ?

Of course in a system with can handle many types of events, but perhaps we are in DDD, the main focus will be on Domain Events , and in the book :

There may be a number of different kinds of events that enter and exit a hexagon. We are interested specifically in Domain Events. The application may also subscribe to system, enterprise, or other types of events as well. Perhaps those deal with system health and monitoring, logging, dynamic provisioning, and the like. Yet, it is the Domain Events that convey the happenings requiring our modeling attention.

N.B: The flow of events will go from one output port to an input port.

The Domain Events published by one such system through the output Port would be delivered to subscribers represented in the others through their input Port. The various Domain Events received have a specific meaning in each receiving

C. Pipes and Filters

In EDA there is the concepts of Pipes and Filters , it is important to grasp some characteristics of them , but the main point can be truly understood in the definition

C.1. Filters

A Filter has many characteristics , like the book says :

Filters may process messages without actually filtering. Futhermore Filters receive messages on an inbound Pipe and send messages on an outbound Pipe. Finally Filters connect to inbound and outbound Pipes through a Port. Ports make Hexagonal (Ports and Adapters) a fitting overarching style.

The table below for me explains some key characteristics of filter :

C.2. Pipes

It is a channel where the event goes after the processing in the filter

The Pipe is actually a message channel

N.B: Understand, however, that a messaging Pipes and Filters approach is not exactly like the command-line version, and it is not intended to be. For example, an EDA Filter doesn’t need to actually filter anything. A Filter in an EDA may be used to perform some processing while leaving the message data intact.

Here for example PhoneNumberFinder or MatchedPhoneNumberCounter are Filters !

D. How does it fit in DDD?

I thought also it was so simple but it so well said in the book :

In an actual DDD scenario, Domain Events reflect names meaningful to the business. Step 1 could publish a Domain Event based on the behavioral outcome of an Aggregate in one Bounded Context. Steps 2 through 4 could occur in one or more different Bounded Contexts that receive the initial Event and then publish one of the subsequent ones. Those three steps could create or modify Aggregates in their respective Contexts. It does depend on the domain, but those are common outcomes of handling Domain Events in a Pipes and Filters Architecture. Domain Events They explicitly model business process activity occurrences that are useful for domain-wide subscribers to know about, and they pack unique identity and as many knowledge-conveying properties as necessary to clearly get their point across. Yet this synchronous, step-by-step style can be extended to accomplish more than one thing at the same time.

E. Sagas

Of course because we are in the domain of computer we can have events that processes shortly and long running processes because they can be completed after some days and those ones are called Sagas

The synthetic Pipes and Filters example can be extended to demonstrate another Event-Driven, distributed, parallel processing pattern, namely, Long-Running Processes. A Long-Running Process is sometimes called a Saga

E.1. Handling more than one event

A filter can handle more than one event, for example if a Filter handle two events from two processes, one can be a short running and the other a long running . Because the execution is in parallel now the main issue is to tell to the filter or to inform him that the long running one has finished his work

Extending the previous example, we could create parallel pipelines by adding just one new Filter, TotalPhoneNumbersCounter, as an additional subscriber to AllPhoneNumbersListed. It receives the Event AllPhoneNumbersListed virtually in parallel with the PhoneNumberFinder. The new Filter has a very simple goal, counting all existing contacts. This time, however, PhoneNumberExecutive both starts the Long-Running Process and tracks it through completion.

And the point for the filter is :

Now it is the responsibility of PhoneNumberExecutive to subscribe to two Events, both MatchedPhoneNumbersCounted and AllPhoneNumbersCounted. The parallel processing is not considered completed until both of these Domain Events are received.

F. How to know the end of the long running process ?

There is a problem with this Long-Running Process, however. The
PhoneNumberExecutive currently has no way of knowing that it has received the two completion Domain Events associated with the specific, corresponding parallel processes.

We can combine two ways to give a solution to the problem.

F.1. Unique ID

The first step in the solution to this troublesome situation is to assign a unique Process identity that is carried by each of the associated Domain Events. This could be the same identity assigned to the originating Domain Event that causes the Long-Running Process to begin (for example, AllPhoneNumbersListed). We could use a universally unique identifier (UUID) allocated specifically to the Process.

F.2. Tracker

Create a Tracker that tracks each of the associated events of course with the verification of the ID of the associated events

In an actual domain each instance of a Process executive creates a new Aggregate-like state object for tracking its eventual completion. The state object is created when the Process begins, associating the same unique identity that each related Domain Event must carry. It may also be useful for it to hold a timestamp of when the Process began (the reasons are discussed later in the chapter). As each pipeline in the parallel processing completes, the executive receives a corresponding completion Event. The executive retrieves the state tracking
instance by matching the unique Process identity carried by the received Event and sets a property that represents the step just completed.

Not to be overlooked is that the Long-Running Process executive can publish one, two, or more Events to initiate the parallel processing. There may also be not only two, but three or more subscribers to any initiating Event or Events. In other words, a Long-Running Process may lead to many separate business process activities executing simultaneously.

G. Event Sourcing

G.1. The Problem

With an increased desire for even more change tracking, the business demands more metadata. It begins to care also about the individual operations that were executed over time. Maybe it even wants to understand how long certain operations took to execute. Those desires lead to the need to maintain an audit log or journal of the finer-grained use case metrics. But an audit log or journal has its limitations. It can convey some information about what has happened in the system, perhaps even allowing for some debugging. But it doesn’t allow us to examine the state of individual domain objects before and after specific kinds of changes. What if we could stretch more out of change tracking?

G.2. Why we need it ?

As developers we have all experienced finer-grained change tracking in one form or another. The most common example is with the use of a source code repository, such as CVS, Subversion, Git, or Mercurial. What all of these variations of source revision management systems have in common is that they all know how to track changes that occur on a source file. The change tracking provided by this genre of tool enables us to go all the way back in time, to view a source code artifact from its very first revision, and then to proceed revision by revision, all the way to the very latest. When committing all source files to revision control, it can track changes of the whole development life cycle.

G.3 Solution

Now, if we think about applying this concept to a single Entity, then to an Aggregate, then to every Aggregate in the model, we can understand the power of change tracking objects and the value it can produce in our systems. With that in mind, we want to develop a means to know what occurred in the model to cause the creation of any given Aggregate instance, and also what has happened to that given Aggregate instance throughout time, operation by operation. Given the history of everything that’s happened, we could even support temporal models. This level of change tracking is at the heart of a pattern named Event Sourcing.

Conclusion : For me that architecture is for a very low coupling between bounded contexts and to make everyone independent, because the only thing that link a Bounded context to another is the Domain Event

See you next time 😁 if you want to add some insights feel free to comment !

Patterns of Enterprise Application Architecture - Distribution Strategies

DevByJESUS — Wed, 11 Jun 2025 08:56:51 +0000

We continue in the chapter Distribution Strategies 😉

A. The Problem

The author says :

However, distribution of objects, or indeed of anything else, has a lot more pitfalls than many people realize [Waldo et al.], especially when they’re under the influence of vendors’ cozy brochures. This chapter is about some of these hard lessons

The point is : How can we make distribution of objects efficient in our system ?

B. The Bad

The most popular way is to take each Object and put them in a seperate node for performance , like in the image below :

But the author says :

Transparency is valuable, but while many things can be made transparent in distributed objects, performance isn’t usually one of them. Although our prototypical architect was distributing objects the way he was for performance reasons, in fact his design will usually cripple performance, make the system much harder to build and deploy, or, usually, do both.

N.B: Why putting everything in a single node is bad ? :

Simply because local call and remote call on the point of performance are not same :

The primary reason that the distribution by class model doesn’t work has to do with a fundamental fact of computers. A procedure call within a process is very, very fast. A procedure call between two separate processes is orders of magnitude slower. Make that a process running on another machine and you can add another order of magnitude or two, depending on the network topography involved.

C. The Good

The way is to be proficient with our multiple processors environment and the author says :

Hence, we get to my **First Law of Distributed Object Design: Don’t distribute your objects! How, then, do you effectively use multiple processors? In most cases the way to go is clustering. Put all the classes into a single process and then run multiple copies of that process on the various nodes. That way each process uses local calls to get the job done and thus does things faster.**

D. Be Pragmatic with Clustering

Because there will always be case where distribution is inevitable for objects and the author to say The rub is that there are limits to that approach—that is, places where you need to separate the processes.

Some examples :

1. Separation is between the traditional clients and servers of
business software

2. Separation between server-based application software (the application server) and the database

Colleen Roe’s memorable phrase, is to be “parsimonious
with object distribution.”

E. Minimizing the coupling in distribution

As you design your system you need to limit your distribution boundaries as much as possible, but where you have them you need to take them into account. We can do it with some solutions :

E.1. Remote Facade

The coarse-grained objects don’t really do anything but
delegate so they act as a facade for the fine-grained objects. This facade is there only for distribution purposes—hence the name Remote Facade (388). Using a Remote Facade (388) helps minimize the difficulties that the coarsegrained interface introduces. This way only the objects that really need a remote service get the coarse-grained method, and it’s obvious to the developers. Remote Facade

E.2. Data Transfer Object

You usually can’t send the domain object itself, because it’s
tied in a Web of fine-grained local inter-object references. So you take all the data that the client needs and bundle it in a particular object for the transfer—hence the term Data Transfer Object (401). (Many people in the enterprise Java community use the term value object for this, but this causes a clash with other meanings of the term Value Object (486)). The Data Transfer Object (401) appears on both sides of the wire, so it’s important that it not reference anything that isn’t shared over the wire. This boils down to the fact that a Data Transfer Object (401) usually only references other Data Transfer Objects (401) and fundamental objects such as strings. DTO

Finally what we can say that these are the patterns to be efficient with distribution of objects !

End of that chapter , See you ❤️

Implementing Domain Driven Design - CQRS

DevByJESUS — Tue, 10 Jun 2025 09:11:07 +0000

We continue our series in the chapter 4 about Architecture 😁

A. What's the problem ?

How can we retrieve all the data users need to view and do it correctly and especially when the domain is complex ? we can do it with repositories in combination with DTOs but it will not be optimal

B. The Solution

The answer lies in the oddly named architecture pattern CQRS ( Command Query Responsibility Segregation ). It is the result of pushing a stringent object (or component) design principle, command-query separation (CQS), up to an architecture pattern.

C. The Definition

C.1. Basic

Bertrand Meyer, asserts the following:

Every method should be either a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer. More formally, methods should return a value only if they are referentially transparent and hence possess no side effects.

C.2. Technical

1. If a method modifies the state of the object, it is a command, and its method must not return a value. In Java and C# the method must be declared void.

2. If a method returns some value, it is a query, and it must not directly or indirectly cause the modification of the state of the object. In Java and C# the method must be declared with the type of the value it returns.

D. how is it applied ?

There is two steps, designing the Command Model and after tuning the Query Model

D.1. Command Model

Now think of segregating all of the pure query responsibilities traditionally found in a model from all responsibilities that execute pure commands on the same model. Aggregates would have no query methods (getters), only command methods. Repositories would be stripped down to an add() or save() method (supporting both creation and updating saves) and only a single query method, such as fromId(). The single query method takes the unique identity of an Aggregate and returns it. A Repository could not be used to find an Aggregate by any other means, such as by filtering on some additional properties. With all of that removed from the traditional model, we designate it a command model.

D.2. Query Model

To fully understand the design of the Query Model we have to do a deep dive in the details of the CQRS Pattern for each of the components of the figure below :

D.2.A Client and Query Processor

The client (at the far left in the diagram) may be a Web browser or a custom desktop user interface. It uses a set of query processors running on a server. The diagram doesn’t show architecturally significant divisions between tiers on the server(s). Whatever tiers exist, the query processor represents a simple component that only knows how to execute basic queries on a database, such as a SQL store.

D.2.B Query Model (or Read Model)

The query model is a denormalized data model. It is not meant to deliver domain behavior, only data for display (and possibly reporting). If this data model is a SQL database, each table would hold the data for a single kind of client view (display). The table can have many columns, even a superset of those needed by any given user interface display view. Table views can be created from tables, each of which is used as a logical subset of the whole

D.2.C Command Processors

A command submission is received by a Command Handler/processor, which can have a few different styles. We consider those styles here, along with some advantages and disadvantages.

We can use a categorized style with several Command Handlers in one Application Service. This style creates an Application Service interface and implementation for a category of commands. Each Application Service could have multiple methods, one method declared for each type of command with parameters that fits the category. The primary advantage here is simplicity. This kind of handler is well understood, easy to create, and easy to maintain.
We can create a dedicated style handler. Each one would be a single class with one method. The method contract facilitates a specific command with parameters. This has clear advantages: There is a single responsibility per handler/processor; each handler may be redeployed independently of others; handler types can be scaled out to manage high volumes of certain kinds of commands.

D.2.D Command Model (or Write Model)

Executes Behavior As each command method on the command model is executed, it completes by publishing an Event. This is the linchpin for updating the query model with the most recent changes to the command model. If using Event Sourcing, the Events are also necessary for persisting the state of the Aggregate that has just been modified. However, it is not a necessity to use Event Sourcing with CQRS. Unless Event logging is a requirement specified by the business, the command model can be persisted using an object- relational mapper (ORM) to a relational database or some other approach. Either way, a Domain Event must still be published to ensure that the query model is updated.

D.2.E Event Subscriber Updates the Query Model

A special subscriber registers to receive all Domain Events published by the command model. The subscriber uses each Domain Event to update the query model to reflect the most recent changes to the command model. This implies that each Event must be rich enough to supply all the data necessary to produce the correct state in the query model.

N.B : Should the updates be performed synchronously or asynchronously? It depends on the normal load on the system, and possibly also on where the query model database is stored. Data consistency constraints and performance requirements will influence the decision.

E. Eventual Consistency

E.1. Trade-off

To update synchronously, the query model and command model would normally share the same database (or schema), and we would update the two models in the same transaction. That keeps both models completely consistent. Yet, this will require more processing time for the multiple table updates, which may not meet the service-level agreement (SLA). If the system is normally under heavy load and the query model update process is lengthy, use asynchronous updates instead. This may lead to challenges of eventual consistency, where the user interface will not immediately reflect the most recent changes in the command model. The lag time is unpredictable, but it is a trade-off that may be necessary to meet other SLAs.

E.2. A way to give a solution

One technique suggested by [Dahan, CQRS] always explicitly displays on the user interface the date and time of the data from the query model that a user is currently viewing. To do so, each record in the query model needs to maintain the date and time of the latest update. This is a trivial step, generally supported by a database trigger. With the date and time of the latest update, the user interface can now inform the user how old the data is. If the user determines that the data is too stale to use, he or she can at that time request fresher data. Admittedly this approach is lauded by some as an effective pattern and heavily criticized by others as a hack or artifice. Certainly these opposing viewpoints indicate the need to perform user acceptance tests before this approach is employed in our own systems.

Conclusion : As with every pattern, CQRS introduces a number of competing forces. We must exercise a great deal of care and choose wisely.

See you next time 😁 by the grace of JESUS, This year i will try to be more consistent !

Implementing Domain Driven Design - Day 7

DevByJESUS — Fri, 17 Jan 2025 11:03:16 +0000

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 😁

Patterns of Enterprise Application Architecture - Day 7

DevByJESUS — Thu, 02 Jan 2025 10:50:45 +0000

We continue in our chapter of Web Presentation
Today we will discuss View Patterns and Input Controller patterns 😉

A. View Patterns

On the view side there are three patterns to think about: Transform View (361), Template View (350), and Two Step View (365). These give rise to essentially two choices: whether to use Transform View (361) or Template View (350), and whether either of them uses one stage or a Two Step View (365). The basic
patterns for Transform View (361) and Template View (350) are single stage. Two Step View (365) is a variation you can apply to either.

keep calm , i know there is just words and no images, let's go 😄

A.1. Template View

Here we do not need any images because the explanation is very clear, look what the book says :

Template View allows you write the presentation in the structure of the page and embed markers into the page to indicate where dynamic content needs to go. Quite a few popular platforms are based on this pattern, many of which are the server pages technologies (ASP, JSP, PHP) that allow you to put a full programming language into the page. This clearly provides a
lot of power and ﬂexibility; sadly, it also leads to very messy code that’s difﬁcult to maintain. As a result if you use server page technology you must be very disciplined to keep programming logic out of the page structure, often by using a helper object.

A.2. Transform View

Again like Template View the words in the books are enough :

The Transform View uses a transform style of program. The usual example is XSLT(Extensible Stylesheet Language Transformations). This can be very effective if you’re working with domain data that’s in XML format or can easily be converted to it. An input controller picks the appropriate XSLT stylesheet and applies it to XML gleaned from the model.

⁉️ Single Stage

The basic patterns for Transform View and Template View are single stage

A.3. Two Stage View

A two-stage view (Figure 4.3) breaks this process into two stages, producing a logical screen from the domain data and then rendering it in HTML. There’s one ﬁrst-stage view for each screen but only one second-stage view for the whole application. The advantage of the Two Step View (365) is that it puts the decision of what HTML to use in a single place. This makes global changes to the HTML easy since there’s only one object to alter in order to alter every screen on the site. Of course, you only get that advantage if your logical presentation stays the same, so it works best with sites where different screens use the same basic layout. Highly design intensive sites won’t be able to come up with a good logical screen structure.

B. Input Controller Patterns

B.1 Page Controller

In the simplest case this Page
Controller (333) can be a server page itself, combining the roles of view and input controller. In many implementations it makes things easier to split the input controller into a separate object. The input controller can then create appropriate models to do the processing and instantiate a view to return the result. Often you’ll ﬁnd that there isn’t quite a one-to-one relationship between
Page Controllers (333) and views. A more precise thought is that you have a Page Controller (333) for each action, where an action is a button or link. Most of the time the actions correspond to pages, but occasionally they don’t.

B.2 Front Controller

Front Controller (344) goes further in this separation by having only one object handling all requests. This single handler interprets the URL to ﬁgure out what kind of request it’s dealing with and creates a separate object to process it. In this way you can centralize all HTTP handling within a single object, avoiding the need to reconﬁgure the Web server whenever you change the action structure of the site

End of that chapter ❤️

Implementing Domain Driven Design - Day 6

DevByJESUS — Thu, 02 Jan 2025 10:09:28 +0000

We continue our series, again on chapter 4 about Architecture
Let's go 😆

A. Hexagonal Architecture

With the Hexagonal Architecture, Alistair Cockburn codified a style to produce symmetry. It advances this goal by allowing many disparate clients to interact with the system on equal footing. Need a new client? Not a problem. Just add an Adapter to transform any given client’s input into that understood by the internal application’s API. At the same time, output mechanisms employed by the system, such as graphics, persistence, and messaging, may also be diverse and swappable. That’s possible because an Adapter is created to transform application results into a form accepted by a specific output mechanism.

1️⃣ Diagram

2️⃣ Definition ?

We usually think of the place where clients interact with the system as its “front end.” Likewise, we consider the place where the application retrieves persisted data, stores new persistent data, or sends output as its “back end.” But Hexagonal promotes a different way of looking at the areas of a system, as indicated by Figure 4.4. There are two primary areas, the outside and the inside. The outside enables disparate clients to submit input and also provides mechanisms to retrieve persisted data, store the application’s output (for example, a database), or send it elsewhere along its way (for example, messaging).

3️⃣ The Left Side

Each client type has its own Adapter [Gamma et al.], which
transforms input protocols into input that is compatible with the application’s API—the inside. Each of the hexagon’s sides represents a different kind of Port, for either input or output. Three of the clients’ requests arrive via the same kind of input Port (Adapters A, B, and C), and one uses a different kind of Port
(Adapter D). Perhaps the three use HTTP (browser, REST, SOAP, and so on) and the one uses AMQP (for example, RabbitMQ). There is not a strict definition of what a Port means, making it a flexible concept. In whatever way Ports are partitioned, client requests arrive and the respective Adapter transforms their input. It then invokes an operation on the application or sends the application an event. Control is thus transferred to the inside.

4️⃣ The Right Side

What about the other side of the application, to the right? Consider Repository implementations as persistence Adapters, providing access to previously stored Aggregate instances and storage for new ones. As depicted in the diagram (Adapters E, F, and G), we might have Repository implementations for relational databases, document stores, distributed cache, and in-memory stores. If the application sends Domain Event messages to the outside, it would use a different Adapter (H) for messaging. The output messaging Adapter is the opposite of the input Adapter that supports AMQP and thus goes out a different Port from the one used for persistence.

B. Why The Hexagonal Architecture ?

A big advantage with Hexagonal is that Adapters are easily developed for test purposes. The entire application and domain model can be designed and tested before clients and storage mechanisms exist. Tests could be created to exercise ProductService well before any decision is made to support HTTP/REST, SOAP, or messaging Ports. Any number of test clients can be developed
before the user interface wireframes have been completed. Long before a persistence mechanism is selected for the project, in-memory Repositories can be employed to mimic persistence for the sake of testing. See Repositories (12) for details on developing in-memory implementations. Significant progress can be made on the core without the need for supplementary technical components.If using true Layers, consider the advantages of toppling the structure and developing based on Ports and Adapters instead. When designed properly, the hexagon inside—the application and domain model—will not leak to the outside parts. This promotes a clean application boundary inside in which use cases are implemented. Outside any number of client Adapters can support
numerous automated tests and real-world clients, as well as storage, messaging, and other output mechanisms.

C. Conclusion

Because the Hexagonal Architecture is versatile, it could well be the foundation that supports other architectures required by the system. For instance, we might factor in Service-Oriented, REST, or an Event-Driven Architecture; The Hexagonal style forms the strong foundation for supporting any and all of those additional architectural options.

see ya 😌