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 used by Domain-driven design:
Some of the features a Domain-driven design framework should support:
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 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.
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;
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;
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.
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:
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.
DAOs are related to persistence, and persistence is infrastructure, not domain. DAOs are injected into Repositories to handle the impedance mismatch that a relational database has with object-oriented techniques. It’s the responsibility of the UserRepository to work with all necessary DAOs and provide all data access services to the domain model in the language which the domain understands.
Lets create a UserRepository class to isolate the domain object from details of the DAO:
interface UserRepository
{
public function find($id);
}
class UserRepositoryImpl implements UserRepository
{
private $databaseDao;
public function setDatabaseDao(UserDao $dao) {}
public function getDatabaseDao() {}
public function find($id)
{
$row = $this->getDatabaseDao()->find($id);
return new User($row);
}
}
The User DAO class will look something like this:
interface UserDao
{
public function find($id);
}
class UserDatabaseDaoImpl implements UserDao
{
public function find($id)
{
$dataSource = Zf_Orm_Manager::getInstance()->getDataSource()
$db = $dataSource->getConnection('slave');
$query = $db->select()->from('user')->where('id = ?', $id);
return $db->fetchRow($query);
}
}
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.
Some of the Domain-driven design concepts explained above are applied in this sample application.
app/
config/
controllers/
UserController.php
domain/
entities/
User.php
UserProfile.php
repositories/
UserRepository.php
UserProfileRepository.php
views/
lib/
public/
The domain layer should be well separated from the other layers and it should have few dependencies on the framework you are using.
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 User
{
private $id;
private $name;
/* @var UserProfile */
private $profile;
public function __construct($id, $name)
{
$this->id = $id;
$this->name = $name;
}
public function setProfile(UserProfile $profile)
{
$this->profile = $profile;
}
public function getProfile()
{
if (null === $this->profile) {
$profileRepository = new UserProfileRepository();
$row = $profileRepository->findByUserId($this->id);
$profile = new UserProfile($row['id']);
$this->setProfile($profile);
}
return $this->profile;
}
}
class UserProfile
{
private $id;
public function __construct($id)
{
$this->id = $id;
}
}
A collection is simply an object that groups multiple elements into a single unit.
class Users
{
private $elements = array();
public function __construct(array $users)
{
foreach ($users as $user) {
if (!($user instanceof User)) {
throw new Exception();
}
$this->elements[] = $user;
}
}
public function toArray()
{
return $this->elements;
}
}
The UserDAO class allows data access mechanisms to change independently of the code that uses the data:
interface UserDao
{
public function find($id);
public function findAll();
}
class UserDatabaseDao implements UserDao
{
public function find($id)
{
$dataSource = Zf_Orm_Manager::getInstance()->getDataSource()
$db = $dataSource->getConnection('slave');
$query = $db->select()->from('user')->where('id = ?', $id);
return $db->fetchRow($query);
}
public function findAll()
{
...
return $db->fetchAll($query);
}
}
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 can inject dependencies on demand, making the instantiation process inexpensive.
class UserRepository
{
/* @var UserDatabaseDao */
private $databaseDao;
/* @var UserProfileRepository */
private $profileRepository;
// Getters and setters
public function setDatabaseDao(UserDao $dao) {}
public function getDatabaseDao() {}
public function setUserProfileRepository(Repository $repository) {}
public function getUserProfileRepository() {}
public function find($id)
{
$row = $this->setDatabaseDao()->find($id);
return new User($row['id'], $row['name']);
}
public function findAll()
{
$users = array();
$rows = $this->setDatabaseDao()->findAll();
foreach ($rows as $row) {
$users[] = new User($row['id']);
}
return new Users($users);
}
}
class UserProfileRepository
{
/* @var UserProfileDatabaseDao */
private $databaseDao;
// Getters and setters
public function setDatabaseDao(UserProfileDao $dao) {}
public function getDatabaseDao() {}
public function findByUserId($id)
{
$row = $this->setDatabaseDao()->findByUserId($id);
return new UserProfile($row['id']);
}
}
Usage:
$repository = new UserRepository(); $user = $repository->find(1); $profile = $user->getProfile(); $users = $repository->findAll();