I don’t like classes like *Service, with bunch of business methods – aka anemic model. I was thinking, instead, to have a class per use case. This was inspired (if not the same) from CQRS. Even if we are not using event sourcing, I believe that this kind of encapsulation would make sense. Then the service layer (application layer) would simple consist of commands that user can instantiate and pass to some executer.
Would this make sense?
Here are some requirements (example):
- user creates a poll with a question and at least 2 choices
- user updates poll and choices; choices can be only added
- user may vote for a choice, question update time must be updated
etc.
These are business scenarios/use cases – however you want to call them. They contain business logic (like we need at least 2 choices etc). I was thinking in:
public class CreatePollCommand implements Command {
@Inject
Repository_Validator_whatever_infrastructure_we_need
public CreatePollCommand(input_arguments) {
}
public void execute() {
// write business logic here
}
}
And this can be used from presentation layer:
executor.run(new CreatePollCommand(input_from_ui));
Then executor injects whatever he needs to inject and thats it.
3
The presence of a service layer does not necessarily imply the model is anemic. A service layer might provide a simplified facade to a complex domain model. I.e. a business user may just want to create a new poll. The UI is simplified if it speaks in those terms and the service layer would translate from what the UI understands into operations leveraging the domain model.
Whether it is an executor interpreting Commands or calls on a service layer in the end someone will perform operations against the domain model.
Now if the executor/service layer is responsible for doing all the CRUD on the objects to perform the transaction, then you have an anemic model.
Let’s make an example.
Your model on the backend will have a Poll with Questions that have Answers there will be an Owner for the poll (most likely the person creating it) along with a number of other objects created (billing, auditing, etc.) that the User might not see. The Poll might have a certain number of allowed Respondents (identified by an email list) and Invitations might have to be generated for the respondents (emails)
Now imagine if your executor was responsible for generating all of those objects directly and linking them together…that would be an anemic model. A robust model would use the Aggregate root to handle all of the required operations.
For example the Executor might get the Account that the poll will be created under and call
var poll =Account.CreatePoll(cmd.PollName, cmd.CampaignId /*you get the point*/);
The Account object would be responsible for creating the poll and tying it to the account, campaign, and other details that it understands about how its polls operate. It would also add the poll to its Polls collection.
Next the executor would perform the rest of its operations on the Poll returned from the prior call.
foreach (var question in cmd.Questions)
{
poll.AddQuestion(question.Prompt, question.Answers);
}
//cmd.Respondents is a comma separated list of strings containing respondent emails
//or a list of emails
poll.AddRespondents(cmd.Respondents);
unitOfWork.Commit();
As you see the robust model takes simple objects and constructs the appropriate domain objects according to internal logic. With an anemic model, the executor or service layer would be responsible for instantiating each question and adding it to a Poll.Questions property. And doing the same with the Answers. There might even be intermediate objects between the questions and poll that the poll would be responsible for constructing because it owns its aggregate.
Either way you slice it, the command or service layer is designed to simplify the complexity of the domain for its clients.
1