Should I Create Domain Object Defaults in my Service Layer?

Question

I am building a MVC application with Zend Framework. The Model includes separate Domain and Mapper layers, and a Service layer sits on top.

For some of my Domain objects, when I create a new instance I need to create other Domain objects which are composed by the first object. For example, when I create a new Organisation object I might add an Employee object (based on the current user), and a Location object (based on the current user's location).

So far I have been creating these in the constructor of the parent object (in this case, Organisation). This is OK, however it does create unnecessary dependencies between Organisation and it's children.

I would prefer to create the children in the Service layer, but am I letting myself in for trouble if I do this?

After reading Martin Fowlers (POEAA) chapter on the Service Layer, I think it comes down to whether this is Domain Logic or Application/Workflow logic. Seems to me that it's borderline... (Note that my service layer is already more than just a facade).

Answer 1

As I understand from your description, currently both the Employee and Location are mandatory dependencies for every instance of Organization. When you are creating this dependencies in the constructor, you create two problems here (thy are kinda like two ends of same ugly stick):

• The Organization class becomes tightly coupled to the names of "Employee" and "Location"

• It becomes very hard to test the behavior of Organization instances, because you have no direct control over its dependencies. You are unable to isolate the "unit under test".

_{Note A: actually an organization require a collection of employees/members, with minimum number of one. In this case a collection of domain objects would seem like a better choice from bit aspects of logic and API implementation.}

To avoid these problems there are two solution for situation when you have to create a complicated object graph:

1. Use a factory (supplemented by properly implemented DIC), which creates all the requirements of your Organization class and injects them, when you are constructing new instance.

2. Create the create all the dependencies and then inject them manually in the Organization, when instantiating the object.

_{Note B: to create domain any domain objects within a service you should be using a factory for said objects. To facilitate this, you would have to inject a domain object factory in the constructor of any service, that you instantiate. Otherwise you just end up with classes that are coupled to names of other classes.}

The choice would depend on what else you want to do with the Employee EmployeeCollection and Location instances in that and similar cases and on what style you prefer.

If you are doing extensive and very specific manipulation with these dependencies, then they should definitely be instantiated separately (via a simple domain object factory) and only then injected. If you are only creating an object graph, the the DIC-based factory would be favorable solution.

_{P.S.: I would recommend for you to watch the The Clean Code Talks - Don't Look For Things! lecture.}