When we use AkKA-related tools and techniques, DDD helps us design actors, design the other components that make up the entire system, the way applications are separated into smaller systems, and understand the boundaries of subsystems and how they interact.

DDD introduced

DDD is a set of guiding principles for software architecture. The most important concept in DDD is the Domain Model. A “domain” is a set of requirements, constraints, and concepts that make up the business or domain you are trying to model. In DDD, we focus on the business domain involved and build the software system model around it.

  • The process of building DDD requires the involvement of experts in the field, who do not need to be computer literate, but can communicate with each other through the new language we have developed
  • DDD focuses on building a sustainable model, not a permanent model

DDD benefits

DDD helps us distinguish between the business area part of the system and the infrastructure part of the system, and helps us strive to create the right abstraction layer around them so that the boundaries are not touched.

The goal of DDD is to break up the larger domain business into smaller, more manageable chunks of business, and then build those smaller chunks separately so that you develop systems that are better understood not only by us but also by domain experts.

DDD components

  • Entity: Entities are generally mutable and have a uniquely identifiable identity that can be mapped directly into Akka Actor. Actors manage mutable state, and all actors in the system can uniquely identify them using paths.
  • Field value objects: Value objects are generally not uniquely identified. If they have the same value, they are considered the same. Value objects are immutable. Can be used as Akka’s message.
  • Aggregation: A collection of objects within an application, each of which is bound to an aggregation root through which some elements of the aggregation can be accessed. In Akka, this is the relationship between parent actor and child actor. If you delete/stop the parent actor, the child actor will also delete/stop
  • Warehousing: The purpose of warehousing is to abstract layers of abstraction from the infrastructure and create a system that isolates the domain from the infrastructure, using SQL databases, NoSQL databases, data files, or other structures without relationships. If you have a set of Person aggregations in Akka, you might have PersonRepository to manage those aggregations. PersonRepository should also be an actor.
  • Domain services: Some operations may involve multiple aggregation roots, in which case we can introduce a concept called Service. A service is also a domain object, but is used to handle operations that are not suitable for aggregation, and the service can interact with the aggregation as needed.

Bounded context

Any system of a certain size will naturally decompose into smaller components, which can have their own domains, with their own boundaries.

In Akka, you can create a series of top-level actors in your system, each dedicated to a specific bounded context that identifies services that are isolated from each other.

This kind of bounded context is very similar to modern microservice architectures, in which each microservice typically represents one bounded context. Tools such as Akka Clustering, clustered Sharding, and Akka Http can be used to break up a large system into separate bounded contexts.

The way actors are deployed is an implementation detail, not an inherent part of the application, so that different parts of the system can be scaled independently

conclusion

Knowing Akka’s actor model and knowing how to work with DDD, you had the building blocks to build a powerful, scalable, highly maintainable system, and you could follow those established patterns to make things work.

Study Notes for Learning Akka design:

Refer to Akka Application Model