A quick comparison of Domain Model vs. Manager (Service) Model

In a domain model we have behavior (and business logic) within our business objects.  In contrast with the Manager (Service) Model our business objects have no behavior and no business logic (except possibly validation logic).  A “Manager” class provides the behavior and applies the business rules.  Let's take a look at an example of each:

Domain Model:

public class Customer {
   // properties
   public string FirstName;
   public string LastName;

   // methods
   public bool Save();
   public bool Delete();
   public Customer Get(int id);
   public CustomerCollection Find(Query aQuery);
}

Vs.

Manager Model

public class Customer {
   // properties
   public string FirstName;
   public string LastName;
} // Note: no behavior

public class CustomerManager {
   public bool SaveCustomer(Customer aCustomer);
   public bool DeleteCustomer(Customer aCustomer);
   public Customer GetCustomer(int customerID);
   public CustomerCollection Find(Query aQuery);
}

As you can see using the Manager Model introduces another class into the mix that performs all the operations on your business objects.  An important thing to note is that the Manager Model and Domain Model are not mutually exclusive.  We could very easily have this:

public class Customer {
   // properties
   public string FirstName;
   public string LastName;
  
   public bool Save();
   public bool Delete();
   public Customer Get(int id);
   public CustomerCollection Find(Query aQuery);
}

public class CustomerManager {
   public bool SaveCustomer(Customer aCustomer) {
      // do pre save stuff, apply aspects, etc.
      aCustomer.Save();
      // do post save stuff, apply aspects, etc.
   }
   public bool DeleteCustomer(Customer aCustomer) {
      // do pre delete stuff, apply aspects, etc.
      aCustomer.Delete();
      // do post delete stuff, apply aspects, etc.
   }

   public Customer GetCustomer(int customerID) { // etc. }
   public CustomerCollection Find(Query aQuery) { // etc.}
}

Essentially with this approach the Manager (Service)  object is working as a facade.  This approach is often beneficial when you have a significant investment in the domain model and want to add a service layer on top.  Rather then just targeting the Customer, the service would likely be broader in scope and include other methods for handling other types of objects.  The scope that the service covers will depend on the application and the anticipated use of the objects within your application.

How else are people using the Manager model and Domain model together.  When does it work?  When doesn't it?  Anyone else care to shed some light on how they define each? 

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Saturday, March 13, 2004 6:12 PM by Wilco    
You could aswell create customers which have a reference to an implementation of a customer manager, which implements logic for things such as saving/deleting etc. You could then delegate the operations on the customer object to the 'associated' manager.

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Sunday, March 14, 2004 4:22 AM by Steve    
Absolutely. My entity objects have behavior such as Save, Delete, and etc but they use other provider/manager classes to actually do all the work. This allows me to swap in new bahavior without having to change my entity objects.

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Sunday, March 14, 2004 5:32 AM by Wilco    
Yeah. However, lets say a data object contains logic (or its factory), for things such as saving. How would you then write business objects which represent those data objects, and let the manager take care of saving the object by reusing the data objects functionality? I guess one way would be to let the business object expose the data object it represents. However, I doubt thats what you want.

Basically, I'm wondering how you would (re)use the generated logic by an O/R mapper, when keeping the logic in the manager.

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Sunday, March 14, 2004 11:34 AM by Steve    
Can you define what you mean when you say business object and data object. Everyone defines them so differently that I want to make sure we're on the same page.

Above when I mentioned that my entity object have behavior, but hand off all the work to a provider/manager I was probably a little unclear. Really its just handing the work off to a provider, not a manager in the sense that I've been talking about. That provider uses an O/R Mapping engine to generate an assembly for persisting my entities. Does that make sense at all?

Let me know how your defining your "business objects" and "data objects." After that hopefully I'll be able to better answer your question :)

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Tuesday, March 16, 2004 4:50 AM by Grant    
I like the Manager model because I generate my "domain" objects from a database using CodeSmith; at the very minimum, I'll derive a class from the database "wrapper" class and include methods in the derived class.

For standard Save() and Update() methods, I defer to a Manager class that has responsibility for determining the SQL from domain object Attributes and executes the data commands.

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Thursday, March 18, 2004 11:02 AM by Sean Chase MCSD.NET    
This is interesting. I use this same manager model in my ASP.NET apps at work for when I create user controls. That way the user controls focus on UI-specific stuff while I have a manager that manipulates the controls. Kind of like the old DoDataExchange.

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Saturday, March 20, 2004 11:39 AM by hBifTs    
I like the Manager Model.In this Model,the Customer looks like a DTO,which is very useful.

# Domain Model or Manager (Service) Model ???

Thursday, March 25, 2004 9:53 PM by hBifTs    
Domain Model or Manager (Service) Model ???

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Saturday, January 08, 2005 11:08 AM by Ken Egervari    
There are advantages to avoiding save/delete/etc. methods in your domain object.

1. Every layer ends up using domain objects. By not putting it into the data access layer (you say manager layer), you are allowing all layers to persist the object. Do you really want JSP's, ASP's, Velocity or Freemarker templates to persist your entities? I would hope not.

2. Your domain logic will not have dependancies on the database APIs. This can be good when the domain objects needed to be shared in a seperate jar file and you want to minimize dependancies.

3. This reduces the complexity, improves maintainability. Database logic is one spot. Domain logic is in another. Allows either to be swapped when you use Interfaces for either/both the domain object or the service object.

4. When domain logic gets really complex, the last thing you want is more logic that has to do with the database, or anything else for that matter. Do you want to handle transactions, security and the databases in each object, in addition to all the actual business logic?

5. It can also be said that the database doesn't actually solve problems in the domain space. Storing an entity into the database is not a business problem; it's a technical problem.

6. By placing database logic in DAO layer, you don't have to pass in connections/providers into your daos upon instantiation or via a property.

7. Domain logic is easier to test when it doesn't depend on the database. Database logic is easier to test when you aren't testing domain logic at the same time. Security, Transactions, etc. can also be tested seperately and you won't have to mock them when you test your domain objects either.

I think my 7 points produce very good reasons why you'd want to seperate the two. And yes, I am an object-oriented programmer. I follow all the design patterns when I write the actual domain logic. But for DAOs (your managers), I most definately put them in seperate classes since it produces more benefits than disadvantages.

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Saturday, January 08, 2005 11:31 AM by Steve    
Ken,

Very good points. Since writing that post I've moved to "managers" or "repositories" for dealing with the persistance of those objects and started trying to keep my domain objects free from database logic. I'm a firm believing in Domain Driven Design (DDD) as Eric Evans describes it in his most excellent book.

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Saturday, January 08, 2005 4:31 PM by Ken Egervari    
If this sort of thing interests you, I wrote some blog entries about these topics if you'd care to read them. I read some other messages on the news groups today that asked similar questions to this and decided to help a few people out.

<a target="_new" href="http://jroller.com/page/egervari">http://jroller.com/page/egervari</a>

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Sunday, January 09, 2005 4:47 AM by Steve    
Thanks Ken, I'll definitely check them out.

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Tuesday, April 04, 2006 11:50 AM by Dan    
My problem with the manager model is that I don't seem to be able to control the business entities and logic as tightly.

For example in the domain model I can set an internal ID such as the primary and the end user of the object cant play with it.

In the manager model I have to make my properties writable or provide methods to update them.

As well as this I can have a fairly complex readonly property that uses the database which I would only populate when requested. To avoid populating this on the initial request would I simply have my DTO reference a method in the manager to return the property or would I have the UI go stright to the manager for the value?

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Tuesday, April 04, 2006 9:50 PM by Steve    
Hey Dan,
I've given both approaches and I consistently find myself coming back to what I call the "Domain Model" above. It's actually the Active Record pattern that we're talkinga bout. In most scenarios like you describe in your comment I've seen the manager populate an object that knows how to lazy load itself (perhaps using the manager) when it's accessed.

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Friday, April 07, 2006 7:13 AM by Dan    
I can see the advantages of using the manager model and it works well when I want to interface with it from another assembly as I can protect properties and methods by making them friends.

My concern really is when the UI BLL and DAL form part of the same assembly and your UI developer can mess with the object in ways that an external assembly can't.

I'm still unsure of how to set 'on demand' properties. I get the feeling putting the call to the manager method in the DTO somewhat breaks the manager model but then having the UI call the manager method directly somewhat breaks the OOP.

It's not that I can't get these things to work for me it's just you seem to be able to chase your tail trying to get answers. I guess the bottom line is there are no real answers but just generally accepted coding patterns that can be 'fixed' for your given project.

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Tuesday, February 20, 2007 12:04 PM by Bloke    
Your definitions are out of whack. What you describe as domain model is actually the active record pattern. Your manager implementation is a domain pattern with repositories. See www.martinfowler.com - the father of P of EAA

# re: A quick comparison of Domain Model vs. Manager (Service) Model

Tuesday, March 06, 2007 11:57 AM by corbin    
I'm actually facing this problem along with adding in SOA into the mix.

If you have SOA do you have to have an anemic domain model by definition? Does all the business logic (what use to belong on the client) like invoice.CalculateTax(); now belong in a service that can be called remotely?


# re: A quick comparison of Domain Model vs. Manager (Service) Model

Tuesday, March 06, 2007 12:22 PM by Steve    
In my opinion, your services layer should be as thin as possible and only be responsible for coordinating different activities. All the actual logic should live where it belongs...in the domain! :)

Post a Comment

 
 
Prove you're not a spammer: 
7 + 7 =