Service Layer

For the demo DDD PHP application I will use the “Service Layer” pattern(http://martinfowler.com/eaaCatalog/serviceLayer.html).

There is another pattern, called Facade (http://en.wikipedia.org/wiki/Facade_pattern) and the Service Layer is a case of it. It is very important to understand that if purely implemented, Service Layer hides everything that lies inside. For instance, in my service layer I could have method like this:

public function add_product_to_cart(...)  

When using the service, I do not know anything about the way this method is done inside. It can be a raw sql query in a huge solid method… or it could be some profound structured practice applied (like DDD). All I know is that I can send some “data” to the service and perhaps get some “data” as the result of its work. Try to think of the service layer as of something your end users have to deal with “directly” (without all those other layers you might have e.g. MVC, external REST API etc).

Data format

How you define the “data” and the interface of interaction with services - is up to you. There are several popular approaches though.

The truly object oriented way and the only “pure” way is to use Data Transfer Objects (DTO). Data wrapped into objects and strengthened with interfaces. This one is considered by many developers as bringing along too much overwork.

Another way to go is to simplify things and use data containers without defining strict interfaces (e.g. simpler objects or even PHP arrays). It’s not an object oriented way at all but who says we have to use it everywhere.

Somewhat straightforward and obvious at the first glance is to use the function parameters to pass data to it. It’s not so comfortable in PHP as it doesn’t have named parameters and may lead to difficulties if the data you need to enter has not trivial structure or if there’s a lot of params. Still it may be very convenient and good enough in a wide range of tasks.

Keep in mind that you can use anything you want. You can use DTOs and be safe in any situation. However for my demonstrative purposes in the sample DDD app coming I’m going to use the following set of compromises for interacting with services:

• to input data to a service method I’ll use function parameters.
• as outcome of a service method’s work I’ll be getting objects that play role of DTOs though are not in fact DTOs but domain objects themselves. Instead of creating interfaces and special DTO classes I’ll enter a project-wide standard, an arrangement under which those objects are only to be used read-only (to get the “data”).
• if a domain logic error occurs anywhere and the current transaction should be canceled I’ll be throwing a DomainExcetion which clients of the service must know how to process.

Logic in Service Layer

If we use Service Layer with DDD then it’s useful to think of it not just of a common facade to all your business and application logic but also as of a place to put logic that doesn’t necessary require a special object by domain design. Consider you have the following requirements for the operation “registering a user”:

• an invite code must be provided
• invite code may only be used to register two users, not more
• to register user must provide a unique email
• person must enter password twice to make sure they’re sure about it and have entered it right
• new user is to be saved in a special storage (e.g. RDBMS)
• an email with a confirmation link should be sent to the registered user

Very typical. So, here instead of entering another domain object called “UserRegistrator” which would embed those domain model details you may have just put the whole operation in a method of a Service. So one Service Layer public method = single atomic business process. Here is how such requirements could be implemented (let’s say it’s a part of UsersService class):

public function registerUser($inviteCode, $email, $password, $repeatPassword)
{
    // NOTE: How we're going to control our dependencies is smth for another 
    // discussion, for now let’s just assume we have the objects we need already.

    $invite = $invitesRepository->findByCode($inviteCode);
    if (!$invite || $invite->countUsersRegistered() >= 2) {
        throw new DomainException('Wrong invite code');
    }

    if ($usersRepository->findByEmail($email)) {
        throw new DomainException('Email is already registered');
    }

    if ($password != $repeatPassword) {
        throw new DomainExceptions('Passwords are not equal');
    }

    $user = new User($email, $password);
    // There's more to say about the atomicity of a single business operation
    // (the confirmation email should not be sent if we failed saving
    // the new user to our database) I'll leave it out for now.

    $usersStorage->save($user);
    $mailer->sendConfirmationEmail($user);
}

Now you should also see the benefit and the very matter of DDD: there is no additional work for a programmer on converting the requirements to the model design except writing those as they are using a programming language.