DDD Philosophy (pt. 1)

• Software will represent a solution to a problem in some business domain
  • it should be modelled & implemented to match that domain
    • i.e. modelling should elicit the key aspects of a domain, possibly by interacting with experts
    • i.e. design and implementation should mirror the domain

• Words do not have meaning per se, but rather w.r.t. a domain
  • i.e. the same word may have different meanings in different domains
  • each domain comes with a particular language characterising it
    • software components (interfaces, classes, etc.) should be named after that language
  • interaction with experts is essential to identify a domain’s language

DDD Philosophy (pt. 2)

• Software should adhere to the domain, at any moment
  • architecture and implementation should favour adherence to the domain
    • in spite of their evolution / modification

• Functionalities, structure, and UX should mirror the domain too

  • using the libraries should be natural for developers
  • UX should be natural for users

  as both developers and users are (supposed to be) immersed in the domain

The Domain

A well established sphere of knowledge, influence or activity

• e.g. some university (department, faculty, HR, etc.), linear algebra, etc.

Contexts

A portion of the domain with a clear boundary:

• relying on a sub-set of the concepts of the domain
• where words/names have a unique, precise meaning
• clearly distinguishable from other contexts

• e.g. departments, divisions, complex numbers, etc.

Domain vs. Context

The domain Model

Set of software abstractions mapping relevant concepts of the domain

• e.g. Java/Kotlin/Scala projects, packages, interfaces, classes, records, methods, etc.

The Ubiquitous Language

• A language structured around the domain model
  • used by all people involved into the domain
  • which should be used in the software
  • in such a way that their semantics is preserved

• underlying assumption:

  • different people call the same things differently
  • especially when they come from different contexts

• commonly reified into a glossary of terms

• used to name software components

Example of context map

Building blocks (concept)

Entities vs. Value Objects

Genus-differentia definition:

• genus: both can be used to model elementary concepts
• differentia: entities have an explicit identity, value objects are interchangeable

Quick modelling examples

Classroom

• Seats in classroom may be modelled as value-objects

• Attendees of a class may be modelled as entities

Seats on a plane

• Numbered seats $\to$ entities

• otherwise $\to$ value objects

Entities vs. Value Objects (constraints)

Value Objects

• Identified by their attributes
  • equality compares attributes alone
• Must be stateless $\Rightarrow$ better to use immutable design
  • read-only properties
  • lack of state-changing methods
• May be implemented as
  • structures in .NET
  • data classes in Kotlin, Scala, Python
  • records in Java
• Must implement equals() and hashCode() on JVM
  • implementation must compare the objects’ attributes

Entities vs. Value Objects (constraints)

Entities

• They have an inherent identity, which never changes during their lifespan
  • common modelling: identifier attribute, of some value type
  • equality compares identity
• Can be stateful $\Rightarrow$ may have a mutable design
  • modifiable properties
  • state-changing methods
• May be implemented via classes in most languages
• Must implement equals() and hashCode() on JVM
  • implementation must compare (at least) the objects’ identifiers

Entities vs. Value Objects (example)

Aggregate Root

Definition

• A composite entity, aggregating related entities/value objects

• It guarantees the consistency of the objects it contains

• It mediates the usage of the composing objects from the outside

  • acting as a façade (à la GOF)

• Outside objects should avoid holding references to composing objects

Aggregate Root (constraints)

• They are usually compound entities

• They can be or exploit collections to contain composing items

  • they may leverage on the composite pattern

• May be better implemented as classes in most programming languages

• Must implement equals() and hashCode() on JVM (as any other entity)

  • implementation may take composing items into account

• Components of an aggregate should not hold references to components of other aggregates

  • that’s why they are called aggregate roots
  • notable exception: references to identifiers of other aggregates

  

Aggregate Root (example)

(notice the link between Order and Buyer implemented by letting the Order hold a reference to the BuyerID)

Factories (definition)

Objects aimed at creating other objects

Factories (details)

Purpose

• Factories encapsulate the creation logic for complex objects

  • making it evolvable, interchangeable, replaceable

• They ease the enforcement of invariants

• They support dynamic selection of the most adequate implementation

  • while hiding the actual implementation choice

Remarks

• DDD’s notion of factory is quite loose
  • DDD’s Factories $\supset$ GOF’s Factories $\cup$ Builders $\cup$ …

Factories (constraints)

• They are usually identity-less and state-less objects

  • recall the abstract factory pattern

• May be implemented as classes in most OOP languages

• Provide methods to instantiate entities or value objects

• Usually they require no mutable field/property

• No need to implement equals() and hashCode() on JVM

Factories (example)

Repositories (definition)

Objects mediating the persistent storage/retrieval of other objects

Repositories (details)

Purpose

• Hiding (i.e. be backed by) some database technology
• Possibly realising some sort of object-relational mapping (ORM)
• Storing / retrieving aggregate roots as wholes
• Supporting CRUD operations on aggregate roots, and/or wrapping common queries
  • Create, Read, Update, Delete

Remarks

• They may exploit factories for turning retrieved data into objects
• If properly engineered, avoids lock-in effect for database technologies
• Design & implementation may require thinking about:
  • the architecture,
  • the infrastructure,
  • the expected load,
  • etc.

Repositories (constraints)

• They are usually identity-less, stateful, and composed objects

  • state may consist of the stored objects
  • state may consist of DB connections

• May be implemented as classes in most OOP languages

• Provide methods to

  • add, remove, update aggregate root entities
  • select and return one or more entities, possibly in a lazy way
    • this should return Iterable, Collection, or Stream on JVM

• Non-trivial implementations should take care of

  • enforcing consistency, in spite of concurrent access
  • support complex transactions

Repositories (example)

Services

Functional objects encapsulating the business logic of the software
e.g. operations spanning through several entities, objects, aggregates, etc.

Purpose

• Reifying control-related aspects of the software
• Wiring aggregates, entities, and value objects together
• Exposing coarse-grained functionalities to the users
• Providing a façade for the domain
• Make the business logic evolvable, interchangeable, replaceable

Remarks

• Services may be exposed via ReSTful API
• Should be designed keeping current uses cases into account (i.e. design services to be purpose-specific)
  • entities/objects should support future use cases, too (i.e. design entities/objects to be general purpose)

Services (constraints)

• They are usually identity-less, stateless objects

• May be implemented as classes in OOP languages

  • or bare functions in functional languages

• Commonly provide procedures to do business-related stuff

  • e.g. a complex operation…
    • … concerning some particular aggregate root
    • … which does not support the operation directly through its methods
      • (maybe because the operation is use-case specific)
  • e.g. proxying an external service
  • e.g. a complex operation spanning through several aggregates, repositories, factories, etc.

• Non-trivial implementations should take care of

  • supporting concurrent access to the service’s facilities
  • exposing domain events to the external world

Services (example)

Domain Events (definition)

A value-like object capturing some domain-related event
(i.e., an observable variation in the domain, which is relevant to the software)

• actually, only the event notification/description is reified to a type

Domain Events (details)

Purpose

• Propagate changes among portions of the domain model (e.g. contexts, aggregates, entities, etc.)
• Record changes concerning the domain

Remarks

• Strong relation with the observer pattern (i.e. publish-subscribe)

• Strong relation with the event sourcing approach (described later)

• Strong relation with the CQRS pattern (described later)

Domain Events (constraints)

• They are usually time-stamped value objects

• May be implemented as data-classes or records

• They represent a relevant variation in the domain

  • e.g. a change in the state of some entity / repository

• Event sources & listeners shall be identified too

  • who is generating the event?
  • who is consuming the event?

• Infrastructural components may be devoted to propagate events across contexts

  • e.g. a message broker, a message queue, etc.

• [Teacher’s Suggestion]: prefer neutral names for event classes in the model

  • e.g. OrderEventArgs instead of OrderPerformedEventArgs
  • e.g. OrderEvent instead of OrderPerformedEvent
  • the reason: the same OOP type may be used to represent different events:
    • e.g. orderIssued, orderConfirmed, orderCancelled, etc.

Domain Events (example)

Exercise 1 – Simple Store (pt. 2)

Money and exchange rates

• Money is represented by a decimal value and a currency

• Currencies are represented by a name, a symbol and an acronym

  • e.g. Euro, EUR, €
  • e.g. USA Dollar, USD, $

• Exchange rates keep track of the conversion rate

  • from a source currency
  • to a destination currency
  • in a particular moment

• Information about exchange rates can be attained from the Internet

• We can compute the price of each product, in any currency, at any moment

Exercise 1 – Simple Store (pt. 3)

Orders

• Orders are identified by a serial number

• They keep track of the many products ordered by a customer

  • and the amount of copies ordered for each product

• Also, orders keep track of when they have been performed

• All such information may be modified before the order is delivered

• When a new order is registered, many actions should be performed in reaction

• It must be possible to compute the actual total price of an order

  • in a particular moment, using a particular currency

Exercise 1 – Simple Store (pt. 4)

TO-DO

1. Read informal domain description
2. Identify the main domain concepts composing the ubiquitous language
3. Model the domain as Java types (classes or interfaces)
   • the model should include entities, value objects, repositories, factories, and services
4. Structure the Java types according to some module structure compliant with hexagonal architecture
   • i.e. put code into either the domain or application modules
5. Sketch tests and, then, implementation for at least one
   • entity
   • value object
   • factory
   • repository
   • value object

Exercise 2 – Trivial CQRS (pt. 2)

TO-DO

1. Switch the design towards event sourcing, by memorising variations instead of snapshots.
2. Implement the CQRS pattern by splitting the repository into 2 parts:

• a write-model for storing variations
• a read-model for retrieving a snapshot of the counter’s value in a given moment

In practice:

1. provide implementations for the CounterReader and CounterWriter interfaces
2. optionally, test those implementations

Exercise 3 – Anti corruption layer (pt. 2)

TO-DO

1. Extend the model of our domain with new interfaces supporting CSV parsing / writing functionalities
2. Design the interfaces so that they are agnostic of the third-party libraries
   • without corrupting the domain model with library-specific types
3. Provide implementations for the interfaces, using one of the two libraries
4. Sketch tests for the implementations
5. Provide implementations for the interfaces, using the other library
6. Use the same tests as above to prove the two implementations work the same way