Application service layer method to get view form catalog data

Question

I'm trying to use a layered pattern and DDD. But I can't find where should I load the catalogs used to populate comboboxes and listboxes in an edit view of a single model entity. Should I create a single method in the application service layer to get all the lists that I need for a single view, in a viewmodel wrapper? Or should I create one method per every list I need? Or it doesn't belong to the service layer at all?

Answer 1

There are two main tactics to access your data from the presentation layer that all have their pro's and cons. To summarize:

1. Using an application service layer.

An application service layer serves as an API for the presentation layer(s) to the layers below. This means that the application services are boundary objects. You may still expose entities and value objects via the application services, but services and repositories remain completely hidden from the presentation layer.

Advantages:

• Creates a clear separation between layers, which makes the code somewhat easier to develop, refactor, maintain and test especially when working within a team or with several teams.
• If any other presentation needs to be built on top of your application you already have an API to built it on.
• You have a place to separate presentation logic from application logic.

Disadvantages:

• Added wiring code. You'll have to produce a lot of services with methods that delegate almost all of the work. This is the case when you get it right. When you get it wrong you'll end up with an anemic domain model and a obese application services.
• It is near impossible to produce a proper API that will serve a purpose you do not know yet. The proper granularity of service calls can only be determined by their use. If you have only one presentation it is therefore an illusion that your application services will be reusable without change.

A sub-tactic that I have seen is that both application services and domain services are used within the presentation layer, see this article for example. Although I agree with the author's stance that application services and domain services are fundamentally different I disagree that both should be usable from within the presentation layer. The purpose of having an application layer is best served when the application services serve as a boundary. This does increase the amount of wiring code, but makes it easier to add application logic at a later stage. I would therefore argue that if you choose this tactic you go all the way.

2. Using the domain layer directly.

You can simply call the repositories and/or services from within your presentation layer.

Advantages:

• Less wiring code. Makes it easier to see what exactly is going on in small codebases.
• Your domain model will get used in more places making it more resistant to outside influence (providing you're a good coder things get better over time instead of worse).

Disadvantages:

• Pure application logic will either end up in your presentation layer. If another presentation needs to be added you will either have to duplicate that logic or revert to tactic number one.
• Since your domain model may offer several ways of achieving the same goal there is a risk of duplication of logic. Duplicate code is easy to detect and hard to prevent, duplicate logic is hard to detect and easy to prevent.

Another sub-tactic that I have seen in the wild is that the domain services act as a boundary objects to the presentation layer. The repositories are therefore ruled not accessible to the presentation layer. This I would call an anti-pattern since application logic, repository logic and domain logic are clearly different types of logic (to some this is not so clear though). If all needs of the presentation layer need to be met by domain services the domain services will either become delegates to the repositories (bad) and application logic will end up in your presentation layer (may be acceptable) or/and application logic will end up in the the domains services (bad). Domain services in DDD where never meant as boundary objects, but simply as containers of operations related to domain concepts that are not a natural part of an entity or value object. Again, I would therefore argue that if you choose this tactic you go all the way.

Wrap up

I hope I have reduced this rather complex and multi-faceted discussion a bit, so that you may choose which tactic fits your use best. There is no clear consensus in the software industry about these things. I usually pick the first tactic for software that is guaranteed a long live or which has several presentations and the second for software which future is still somewhat uncertain and has a single presentations.