CODEWITHSUNDEEP
c#asp.netdependency-injectiondomain-driven-designpoco
Kevin Boss
Kevin Boss

Reputation: 145

Application Service Objects, should they contain methods which call domain service methods

I am searching for an answer and I couldn't find any.

We have a Domain Layer which contains Services and POCOs. Then we have an ApplicationService Layer which contains Services which delegate the Domain Layer services and also maps the POCOs to upper layer objects.

The upper layer objects get extended. For example we have products. I now have added a method, let it call "getPrice" which calls the "getPrice" method of the price service and passes its own productID as a parameter to retrieve the price of this product. The price service gets introduced trough constructor injection into the product.

Now I am asking myself if this is a bad design. We only extend the objects in the application service, the ones in the domain are still POCOs.

Where are disadvantages in this concept?

Upvotes: 0

Views: 1470

Answers (2)

eulerfx
eulerfx

Reputation: 37739

For an example of the relationship between an application service, domain service and domain entities, take a look here.

In a nutshell, application services encapsulate your domain and delegate behavior to domain objects by coordinating repositories and other services. This seems to be in accord with what you've described.

Where you seem to steer off course is with injecting services into the product entity. This is usually discouraged in DDD. Instead, if a particular behavior on an entity requires a service, pass the service to the method implementing the behavior. Some disadvantages of injecting services into entities are:

  1. Your entity becomes more difficult to reason about.
  2. It must become part of a dependency injection graph further complicating its use.
  3. It violates SRP since there is likely only one behavior which requires the service.

Upvotes: 2

Keith Payne
Keith Payne

Reputation: 3082

You're describing Domain-Driven Design. The overriding problem with DDD is that it is very easy to fall into an "anemic" design - meaning that you've got your domains, services, aggregate roots, repositories, etc.. but they only add unnecessary complexity instead of truly simplifying development.

A specific question - Is your Product entity associated with the application, or is a Product really a domain entity? Does productID have meaning in the scope of the application? Your mention of the ID raises a yellow flag.

Separately:

As a matter of style, I like to keep surrogate keys (like productID) out of the application layer where it serves no purpose except to pass back and forth to the domain. I prefer to rely on natural keys once I get to the application layer.

Upvotes: 1

Related Questions