Skip to main content

Tactical DDD

Now that we have covered the basic principles of DDD, we, as software engineers needs to incorporate these principles in our code. DDD has introduced some programming paradigm to implement the design into the codebase.

Entity​

An Entity is a class that has some sort of identity-making in unique from other identical objects. Commonly, this is a simple class definition, which has state and some rules regarding the life-cycle of that entity.

Commonly software code has many entities. If you look at the Subscribe feature mechanism you might have some of the following entities: Member, Subscription, Feature, Role.

Value Object​

If we have object that can be immutable from the moment we initialize it, we have a value object. Similar to entity, value object is a class with some parameters holding values. However, unlike an entity that can change state, value object stays the same and has no important business logic for the software.

Commonly, value object is used to group information under a same class, but without complexity of introduction of new entity.

For example, if we need to store information about our lunch order for a specific sandwich, in PHP we might have something like this

public class SandwichOrderLine
{
  public function __construct(
    private string $topping,
    private string $bread,
    private int $amount,
  ) { }
}

$orderLineBroodbode = new SandwichOrderLine ("Chicken Teriyaki", "Focacia", 3);

Aggregate​

Aggregate is a collection of objects that represent one concept in the domain. For example, a car is an aggregate of many different objects (design, motor, sales value, etc.).

The aggregate root is the entry-point into the specific aggregate.

Invariant​

Invariants are business rules that the domain is enforcing. They are separate from application-level rules.

Domain Services​

Domain services hold domain logic whereas application services don’t.

Application Services​

Application services orchestrate the execution of domain logic according to outside-world input but don’t contain any domain logic themselves.

There are four layers of DDD architecture: domain/model; infrastructure (code, classes); application (application services), and UI (only talks with the application layer and does not know about domain or infrastructure).

Domain Driven Design​

Domain-Driven Design is an approach to understanding the business in order to represent it in software, and also an architectural pattern for simplifying the business.