Introduction
Terminology
Frameworks
The Ubiquitous Language
Data Access Strategies
The Repository
Sample Application
Directory Structure
User Entity
Users Collection
User DAO
User Repository
Source Code

Introduction¶

Domain-driven design (DDD) is not a technology or a methodology. It’s a different way of thinking about how to organize your applications and structure your code. This way of thinking complements very well the popular MVC architecture.

Domain-driven design separates the model layer “M” of MVC into 3 layers: application, domain and infrastructure. The infrastructure layer is used to retrieve and store data. The domain layer is where the business knowledge or expertise is. The application layer is responsible for coordinating the infrastructure and domain layers to make a useful application. Typically, it would use the infrastructure to obtain the data, consult the domain to see what should be done, and then use the infrastructure again to achieve the results.

Object-oriented programming is the most important element in the domain implementation. Domain objects are designed using classes and interfaces, and take advantage of OOP concepts like inheritance, encapsulation, and polymorphism. Most of the domain elements are true objects with both State (attributes) and Behaviour (methods or operations that act on the state). Entities and Value Objects in DDD are classic examples of OOP concepts since they have both state and behaviour.

Terminology¶

Terminology used by Domain-driven design:

Entity: An object which has a distinct identity. For example, a User entity has a distinct identity with an ID.
Value Object: An object which has no distinct identity, like numbers and dates. For example, if two Users have the same date of birth, you can have multiple copies of an object that represents the date 16 Jan 1982.
Factory: Used to create Entities. For example, you can use a Factory to create a Profile entity from a User entity.
Repository: Used to store, retrieve and delete domain objects from different storage implementations. For example, you can use a Repository to store the Profile your Factory created.
Service: When an operation does not conceptually belong to any object.

Frameworks¶

Some of the features a Domain-driven design framework should support:

A domain model that is independent and decoupled from the application.
A reusable library that can be used in many different domain-specific applications.
Dependency Injection in order to inject Repositories and Services into Domain Objects.
Integration with unit testing frameworks, such as PHPUnit.
Good integration with other frameworks, such as Zend, Symfony, Doctrine, etc.

The Zend Framework, for example, is part of the infrastructure layer and acts as a supporting library for all the other layers. However, the domain layer should be well isolated from the other layers of the application and should not be dependent on the framework you are using.

The Ubiquitous Language¶

The ubiquitous language is the foundation of Domain-driven design. The concept is simple, developers and domain experts share a common language that both understand. This language is set in business terminology, not technical terminology. This ubiquitous language allows the technical team become part of the business.

Data Access Strategies¶

When accessing data from a data source, you have to decide how your application will communicate with a data source. Each data access strategy has its own advantages and disadvantages. Here are some design patterns that support DDD:

Generic DAO’s

Data Access Objects (DAO’s) and Repositories play an important role in DDD. The goal of a DAO is to abstract and encapsulate all access to the data and provide an interface. The DAO always connects, reads and saves data to a data source. From the applications point of view, it makes no difference when it accesses a database, XML file or Web service:

$user = new UserDbDao();
$row = $user->findUserById(456);
echo $row->name;

$user = new UserXmlDao();
$row = $user->findUserById(456);
echo $row->name;

Table Data Gateway

An object that acts as a Gateway to a database table. One instance handles all the rows in the table. The Zend_Db_Table solution is an implementation of the Table Data Gateway pattern:

$user = new User();
$rows = $user->find(456);
$row = $rows->current();
echo $row->name;

More info: Table Data Gateway

Row Data Gateway

An object that acts as a Gateway to a single record in a data source. There is one instance per row. Zend_Db_Table_Row is an implementation of the Row Data Gateway pattern:

$user = new User();
$row = $user->fetchRow($user->select()->where('user_id = ?', 1));
echo $row->name;

More info: Row Data Gateway

Active Record

An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data. The Mad_Model component is an ORM layer that follows the Active Record pattern where tables map to classes, rows map to objects, and columns to object attributes:

$user = new User();
$userFinder = new UserFinder();
$row = $userFinder->find(456);

Data Mapper

A layer of Mappers that moves data between objects and a database while keeping them independent of each other and the mapper itself:

$user = new User();
$userMapper = new UserMapper();
$row = $userMapper->findByEmail($email);

Data Transfer Objects

A Data Transfer Object (DTO) in Domain-driven design is not the same as a Value Object. A DTO is often used in combination with a DAO to encapsulate data. It allows you to reduce communication effort when dealing with a lot of small data entities. For example:

class UserData
{
    public function setId($id) {}
    public function getId() {}
    public function setFirstName($firstName) {}
    public function getFirstName() {}
    public function setLastName($lastName) {}
    public function getLastName() {}
}

$user = new UserData();
$user->setFirstName('Jim');
$user->setLastName('Morrison');

$userDao = new UserDbDao();
$userDao->insert($user);

A DTO is a simple container for a set of aggregated data. It should contain no business logic and limit its behaviour to activities such as internal consistency checking and basic validation. Be careful not to make the DTO depend on any new classes as a result of implementing these methods.

The Repository¶

Repositories play an important part in DDD, they speak the language of the domain and act as mediators between the domain and data mapping layers. They provide a common language to all team members by translating technical terminology into business terminology.

In a nutshell, a Repository:

Is not a data access layer
Provides a higher level of data manipulation
Is persistence ignorance
Is a collection of aggregate roots
Offers a mechanism to manage entities

Injecting DAO's

In DDD, you inject Repositories, not DAO’s in domain entities. In the absence of an ORM framework, the DAO handles the impedance mismatch that a relational database has with object-oriented techniques. For example, imagine you have an entity named User that needs to access the database to retrieve the User details:

class User
{
    // DAO needs to be injected
    private $_dao;
    private $_data;

    public function setDao(UserDaoInterface $dao) {}
    public function getDao() {}

    public function setData($data) {}
    public function getData()
    {
        if (null === $this->_data) {
            $data = $this->getDao()->find($id);
            $this->setData($data);
        }
        return $this->_data;
    }
}

The User DAO class will look something like this:

interface UserDaoInterface
{
    public function find($id);
}

class UserDaoDb implements UserDaoInterface
{
    // Db needs to be injected
    private $_db;

    public function setDb(DbInterface $db) {}
    public function getDb() {}

    public function find($id)
    {
        $db = $this->getDb();

        $query = $db->select();
        $query->from('user');
        $query->where('id = ?', $id);

        return $db->fetchRow($query);
    }
}

$userDao = new UserDaoDb();
$userDao->setDb($db);

$user = new User();
$user->setDao($userDao);
$data = $user->getData();

Is there an easier way to create entities and inject dependencies? The process of creating an entity is complex, because an entity always has relationship with other objects in your domain model. When creating an entity, we have to initialize its relationships as well. Therefore, it’s a good practice to delegate this task to another object.

But, what about separation of concerns? DAO’s are related to persistence, and persistence is infrastructure, not domain. The main problem with the example above is that we have lots of different concerns polluting the domain. According to DDD, an object should be distilled until nothing remains that does not relate to its meaning or support its role in interactions. And that’s exactly the problem the Repository pattern tries to solve.

Injecting Repositories

Lets create a UserRepository class to isolate the domain object from details of the UserDaoDb class:

class User
{
    // Repository needs to be injected
    private $_repository;
    private $_data;

    public function setRepository(UserRepositoryInterface $repo) {}
    public function getRepository() {}

    public function setData($data) {}
    public function getData()
    {
        if (null === $this->_data) {
            $data = $this->getRepository()->getUserById($id);
            $this->setData($data);
        }
        return $this->_data;
    }
}

It’s the responsibility of the UserRepository to work with all necessary DAO’s and provide all data access services to the domain model in the language which the domain understands.

class UserRepositoryInterface
{
    public function getUserById($id);
}

class UserRepository implements UserRepositoryInterface
{
    // DAO needs to be injected
    private $_userDao;

    public function setUserDao(UserDaoInterface $userDao) {}
    public function getUserDao() {}

    public function getUserById($id)
    {
        return $this->getUserDao()->find($id);
    }
}

$userDao = new UserDaoDb();
$userDao->setDb($db);

$userRepo = new UserRepository();
$userRepo->setUserDao($userDao);

$user = new User();
$user->setRepository($userRepo);
$data = $user->getData();

The main difference between the Repository and the DAO is that the DAO is at a lower level of abstraction and doesn’t speak the ubiquitous language of the domain.

Sample Application¶

Some of the Domain-driven design concepts explained above are applied in this sample application. I’m also going to use the Zend Framework infrastructure to speed up some development tasks.

Directory Structure¶

app/     -> Application and UI Layers
domain/  -> Domain Layer
lib/     -> Infrastructure Layer

Application and UI Layers

app/
    controllers/
        UserController.php
    views/
        layouts/
        scripts/

Domain Layer

This layer should be well separated from the other layers and it should have few dependencies on the framework(s) you are using. I’m going to group all the classes and interfaces under the namespace “Project” and add it to my include path:

domain/
    Project/
        Dao/
            Db/
                IUser.php
                IUserProfile.php
                User.php
                UserProfile.php
        Model/
            User/
                IRepository.php
                Repository.php
            User.php
            UserProfile.php
            Users.php

Infrastructure Layer

This layer acts as a supporting library for all the other layers:

lib/
    Zend/
        ...
    Zf/
        Db/
            Adapter.php
            Exception.php
            ReplicationAdapter.php
        Domain/
            Collection.php
            Entity.php
            Exception.php
            Repository.php

User Entity¶

The User and UserProfile objects have a one-to-one relationship and form an Aggregate. An Aggregate is as a collection of related objects that have references between each other. Within an Aggregate there’s always an Aggregate Root (parent Entity), in this case User:

class Project_Model_User extends Zf_Domain_Entity
{
    /* @var int */
    private $id;

    /* @var string */
    private $name;

    /* @var Project_Model_UserProfile */
    private $profile;

    public function __construct($properties)
    {
        $this->define($properties);
    }
}

Usage:

$array = array('id'=>1, 'name'=>'Federico');
$user = new Project_Model_User($array);
$user->setProfile($profile);

echo $user->getId();   // Outputs 1
echo $user->getName(); // Outputs Federico

Users Collection¶

A collection is simply an object that groups multiple elements into a single unit.

class Project_Model_Users extends Zf_Domain_Collection
{
    public function __construct($users)
    {
        foreach ($users as $user) {
            if (!($user instanceof Project_Model_User)) {
                throw new Zf_Domain_Exception(...);
            }
            $this->append($user);
        }
    }
}

User DAO¶

The UserDAO class allows data access mechanisms to change independently of the code that uses the data:

class Project_Dao_Db_User extends Zf_Db_Adapter
{
    public function find($id)
    {
        $db = $this->getConnection();
        $query = $db->select();
        $query->from('user');
        $query->where('id = ?', $id);
        $result = $db->fetchRow($query);

        return $result;
    }

    public function findAll()
    {
        ...
        return $resultSet;
    }
}

User Repository¶

A Repository is basically a collection of Aggregate Roots. Collections are used to store, retrieve and manipulate Entities and Value objects, however, object management is beyond the scope of this post.

The UserRepository object injects dependencies on demand, making the instantiation process inexpensive. A caller method is responsible for dynamically creating the setter and getter methods. You can easily mock objects by passing a custom config array via the constructor.

class Project_Model_User_Repository extends Zf_Domain_Repository
{
    /* @var Project_Dao_Db_User */
    private $userDao;

    /* @var Project_Dao_Db_UserProfile */
    private $userProfileDao;

    /* @var array IoC Spec */
    private $inject = array(
        'userDao'        => 'Project_Dao_Db_User',
        'userProfileDao' => 'Project_Dao_Db_UserProfile'
    );

    public function getUserById($id)
    {
        $row = $this->getUserDao()->find($id);
        $user = new Project_Model_User($row);

        $row = $this->getUserProfileDao()->findByUserId($id);
        $profile = new Project_Model_Profile($row);
        $user->setProfile($profile);

        return $user;
    }

    public function getUsers()
    {
        $users = array();
        $rows = $this->getUserDao()->findAll();
        foreach ($rows as $row) {
            $users[] = new Project_Model_User($row);
        }

        return new Project_Model_Users($users);
    }
}