AppService -> Domain Service -> Repository

samvan · November 4th, 2010, 01:36 AM

Hi,

I have a question regarding how the AppService layer should interact with the domain / repository layer.

I have finished chapter 3 & 4, and in Ch3, the GetAllProductsFor method calls the GetAllProductsFor method in the domain layer which in turn calls the repository, but in Chapter 4, GetAllBankAccounts directly calls the repository.

I am wondering why this is.. is it because we need to call the Apply method (the discount strategy) on the domain entity (list of Products) and we can't do it on the AppService layer?

Maybe the reason will be answered in later chapters.. but in case it won't, can you shed some light?

elbandit · November 4th, 2010, 04:51 AM

Hi Samvan,

Thanks for buying the book!

I don't go into real detail on the role of the application layer apart from the paragraph on page 92. For more information refer to Evans Domain Driven Design book or check out the following article: http://weblogs.asp.net/pgielens/arch...en-Design.aspx. In the book I use the application layer to convert domain entities into viewmodels (chapter 8) for the purpose of displaying in the UX.

Quote:

I am wondering why this is.. is it because we need to call the Apply method (the discount strategy) on the domain entity (list of Products) and we can't do it on the AppService layer?

Basically Yes. In chapter 3 the app service layer calls into the domain service, as the process of returning a list of products requires some business logic to be run (i.e. the working out of correct discount) and to my view this is a domain concern. In chapter 4 returning the list of bank accounts doesn't require any logic so it makes sense to go directly to the repository to return a list of all the accounts.

Hope that helps
Cheers
Scott

Please let me know what you think about the rest of the book or if you have any more questions.

samvan · November 4th, 2010, 01:53 PM

Thanks for the info. I like the book very much (am reading Ch 5 on patterns).

One thing I am unclear about the app service layer: does "role-based authorization" fall into the realm of application service?

Consider this example:

the presentation layer needs to show/hide a Edit button based on a BlogPostResponse (w/ a bool CanEdit property) returned by the App Service layer.

Where should I put the logic to determine the CanEdit property? Should I determine the permission separately (see below) from the Blog Model and set the CanEdit property inside App Service?

The logic will be to compare the User.ID with the BlogPost.AuthorID and see if they match, and maybe see if the user is a global blog editor who has the right to edit all blog posts (e.g the User entity has a IsInRoleType(roleType.GlobalEditor) method ).

elbandit · November 4th, 2010, 04:10 PM

Fair point.

Maybe in this case the application service layer authenticates the user by extracting a user id from a cookie or from some other form of storage (not the concern of the domain). The app server would then query the repository for the user and then supply this to the domain to resolve whether the blog post can be edited. All of these things of course change depending on the type of system you are modelling and the domain rules.

This blog post from Jimmy Bogard details the uses of the various services from a DDD point of view. I use the application service in the same manner i.e. to facilitate message request and response.
http://www.lostechies.com/blogs/jimm...en-design.aspx.

Does that make it clearer?

cmonstoke · December 15th, 2011, 12:35 PM

Hi Scott,
I like what I have read so far only had it a day (along with Professional Enterprise .NET). I have been trying to apply much of what I have learn't in the past and these books are showing me how easily my development skills have become blunt.

Having read chapter 3, I have to say that Model.ProductService and Service.ProductService, does not feel right. Having read the blog post linked above, I now know the cause of the this discomfort, and it is purely down to naming.

I personally don't like Model.ProductService notation and feel that using a typedef (using newName = namespace.type) should only be used for classes that you have no naming control over (thirdparty libraries)

Wouldn't Model.ProductService better convey intent with a name such as ProductModelService ?... leaving ProductService in the Service namespace.

Incidently I wonder if the namespaces could have been named to better convey the layer they represent ? ....

Just my thoughs and I'm sure many will disagree.

Many Thanks for such a good book.

Regards
Mark

elbandit · January 13th, 2012, 08:18 AM

Hi Mark,

Thanks for buying the book and sorry for my late reply. You touch on a very important subject of naming, and you are right to pick up on the fact that Model.ProductService and Service.ProductService don't do a great job of describing exactly what they are doing. Perhaps a better method would have been to allow the Service.ProductService to pull all products required and then to use a Domain Service maybe better named ProductDiscountPolicy rather than Model.ProductService to apply discounts something like....

Service.ProductService

PHP Code:


			
public class ProductService
{
    private ProductDiscountPolicy _productDiscountPolicy;
    private IProductRepository _productRepository;
    
    public ProductService(ProductDiscountPolicy productDiscountPolicy
                          IProductRepository productRepository)
    {
        _productDiscountPolicy = productDiscountPolicy;
        _productRepository = productRepository;
    }

    public ProductListResponse GetAllProductsFor(ProductListRequest productListRequest)
    {
       ProductListResponse productListResponse = new ProductListResponse();
    
        try {
            IList<Model.Product> productEntities = productRepository.FindAll();

            // Applicatgion Service using the Domain Service, in this case named Product Discount Polcity
            productListResponse.Products = _productDiscountPolicy.ApplyDiscountToProducts(productEntities, productListRequest.CustomerType);

            productEntities.ConvertToProductListViewModel();
            productListResponse.Success = true;
        }
            catch (Exception ex)
        {
            // Log the exception…
            productListResponse.Success = false;
            // Return a friendly error message
            productListResponse.Message = &#8220;An error occurred”;
        }        
        return productListResponse;
    }
}

let me know what you think.
Cheers
SCott