first let me make one thing clear. I don’t think there is anything wrong with the approach to having the “domain operations” called by the UI layer. It’s just that in our application we chose to use the Use Cases as operations in the service layer. That does not mean that there is one service method per domain method. This approach leads to very thin client layers that typically only need to do a single call, as a user interface usually deals with one use case at a time. This also makes transaction management very easy. Just annotate the service methods with Spring’s @Transactional, and you’re done. Persistence is managed for you.

As I understand, you prefer to have the UI Controller in charge, and I will not be the one to say that is the wrong way to go. I am sure that, in some circumstances (e.g. when the amount of use cases is simply too high), your approach leads to easier to maintain code than mine. But in our case, and you’ll just have to trust me on that, since I am not allowed to publish the codebase, it just wasn’t the most suitable approach.

And to answer you “service/repository side-by-side question”: no, only the service layer accesses the repositories. The service layer is responsible for checking security rules, retrieving entities, calling the right methods on them, and then persisting their state again. Of course, most of these rules are delegated to more specific implementations (e.g. security strategy).

Anyway, if you have written anything about the approach you use in you applications, I am eager to read about it.

Regards,

Allard

thanks for your response. I’ll try to get it down one by one.

The save method. This actually is a combination of what you might express as create(Entity entity) and update(Entity entity) method combination. I think we can agree on the client having a necessity to create and update entitys it might have edited via the service interface, can’t we? I tend to merge this into one method to make the distincion not to bother the client. Although in very simple cases a call to save might result in a simple delegate to a repository, but in most cases there are additional steps do be done.

Your linkAccount method makes sense as you treat the IDs of entities as value objects. In general we hardly ever need more than a Long so that the additional abstraction does not add much value. I agree that this way the service interface has a more “domainic” surface but the benefit seems rather small to me. In contrast, stripped down to the Long variant, the interface becomes much more technical that if you’d handed out the entity and let the client to the work on the entity itself through domain functionality e.g. account.link(user). To me the service interface you suggest leads to a very procedural way of programming at the client side whereas mine results in a rather thin layer (and thus is much more like a facade) above the multiple repositories. This seconds your thoughts on building modular interfaces.

Regarding your last paragraph: How do you deal with services and repositories in combination then? Do you use them side-by-side from a clients point of view (suppose the mentioned (create, update, getAllFoo) functionality clients will need to access?

Very cool to discuss this stuff here. I really like shading light from different angles on this topic .

Regards,
Ollie

thanks for your reply. I’m not sure I really understand what you mean in your first point. To me, having a “save” method on your service layer is rather technical. Instead, I like to see my application (aka service) layers as the functional boundary of an application. Everything your application is supposed to do, is done within those boundaries. That means that any entities that cross that boundary are detached from any transaction or persistence context and are considered “lost”. You could see the application services as use case controllers.

Your example of linking an account to a user, would have a method like the following on your service layer: public void linkAccount(AccountId accountId, UserId userId), quite similar to what you said.

Inside, you would retrieve the corresponding entities from the repository and use the link method on them.

It doesn’t per-se make it more accessible to a client, but it is the cleanest way to force some form of separation between the application and ui layers. I am not saying this *the* way to do it. It is just a way we did it, and for our application, with relatively few use cases, these simple rules have helped our (relatively small, but flexible) team keep a sound and nicely decoupled codebase in the months that we have been developing this application. We didn’t have any discussions as of where to put certain logic. Everything is clear and well confined within a predefined boundary.

Of course, this approach has some drawbacks if your application has hundreds of different use cases. But still, with a nice modular approach, you should still be able to keep a relatively good overview, even in this case.

About your second option. Persisting domain objects is not the responsibility of the service layer. Repositories are responsible for that.

Hope that clarifies my point of view.

thanks for your comment. You might like my other blog entries about DDD in that case too: http://www.gridshore.nl/category/ddd/

Regards,

Allard

Looking forward to more articles like that.

Christoph

1. Abstraction of the service layer decreases. You get a rather technical un-domain-driven interface of the service layer by doing that.
2. How do you expose persisting the domain object then? It needs transactional boundary, so I tend to expose a save(..) method on the service.

I prefer to let the clients of the service layer use the rich methods of the entities to do more than getters and setters and hand it to the service layer to apply persistence. Let me give an example you can probably follw very easily. You have Accounts and Users that can be linked to each other. How would you expose this functionality to the clients of a service? I’d take the route of offering an Account.link(User user) method, letting that method check certain domain constraints and let this be invoked by the client and hand the account back to the service to persist the operation. If I got you right, you rather offer an link(Long accountId, Long userId) via the service and handle the Account.link(User) call inside the service, right? I don’t see how this makes it more accesible to the clients.

Really look forward to hear your opinions on that!

Regards,
Ollie