Pattern Against Anemic Domain Model

I would like to solicit advice on everyone's thoughts on how best to combat the Anemic Domain Model anti-pattern when building out a system based on web services.

One of our goals is to build a set of core web services that expose the most basic services we reuse repeatedly in our organization, which is the creating of domain models. Right now we have a small library that we share and reuse but as we grow our team it would be much nicer to centralize these basic services. Over time our systems are going to change as some of the data may come from the cloud (Salesforce.com or AWS) so we're not just isolating basic DAO code in a web service but also application integration.

For example, our customer data comes from the accounting, CRM, and order processing systems. Configuration is a real pain because every app that ships needs to be bundled with the core library and configuration on each system. I would like to centralize the creation of models, ala, SOA, but retain a rich model higher up in the Service Layer / Facade.

If you think in general that this is a bad I'd be interested in hearing why!

My thought is to define a domain object Employee that has an EmployeeService injected. At runtime the EmployeeService implementation is an EmployeeWebServiceClientImpl that implements said interface. EmployeeWebServiceClientImpl uses a web service proxy to the server.

On the server-side of the web service we have EmployeeWebService invoking EmployeeDao to query the database. Could just as easily be a class calling out to Salesforce.com to get data. We would share a library that contained the domain model and interface so you would deserialize the web service response directly into a class that contained the needed business logic.

Below is some example code in order from client to server:

```
//Example of client
public static void main(String[] args) {
try {
Employee employee = Employee.getEmployee("james");
if (employee.isEligib

You're adding a lot of complexity here. Plus, you're going against the point of a Service Layer and Domain Model. Your Domain Model should probably use either Active Record or Data Mapper.

The point of a Service Layer is to act as an end point (API) that holds common business logic that deals with integration of domain model objects. Your service layer should just query repositories and delegate calls to process business logic to your domain model (which should hold as much business logic as possible). Injecting it into your domain model adds persistence concerns, which it should not care about.

StackExchange Code Review Q#395, answer score: 3