The Application Layer

Jul 31, 2008 at 11:14 PM

Hi Tim,

Thanks for answering my other questions. I have another :0)

In chapter 2 you explain about what the Application layer is all about, but you don't mention it in any other chapter (I apologise if I have missed it). From the DDD Quickly definition of the Application Layer it states:
"This is a thin layer which coordinates the application
activity. It does not contain business logic. It does not
hold the state of the business objects, but it can hold
the state of an application task progress." 

The only class in the Application is UserSession, which does appear to hold the state of an application task progress, have I missed where you talk about this? Also did you not add any more logic into the application layer because the application uses the default logic of the domain? - i.e. the Domain Service methods were all that you needed. If you were as you say in Chapter 2 going to email interested parties when a project was updated would you put this into the application layer?

Slighty off topic but if I were to use your Domain Model within a web application would my UserSession class look a little more like:

namespace SmartCA.Application
public static class UserSession

                public static Project CurrentProject
get { return (CurrentProject)HttpContext.Current.Session("CurrentProject"); }
set { HttpContext.Current.Session("CurrentProject") = value; }




With the Application Layer now having access to the HttpContext?

Thanks Scott

Aug 1, 2008 at 9:42 AM
Actually having had a bit of time to think about it (and a couple of postings on the Yahoo DDD group), the UserSession class only "holds the state of an application task progress" i.e. the current project. So I wouldn't need to change the Application for a web app, in fact that would be very wrong as the application needs to be unaware of the UI.

So I could use your UserSession class to hold the current project et al, for a user request in a web application. The fact that the class is static doesn't matter because you have said it is a one person application so we don't have to worry about multiple users updating the Current Project. Have I got all of that correct?

Another question is why haven't you defined an API through your Application Layer, I would have expected, from what I have read about the Appliction layer in DDD to see the UI going through the Application Layer in a similar way to Martin Fowlers P of EAA: Service Layer.


P.S. Thanks to your book DDD is starting to make a whole lot of sense to me :0)
Aug 5, 2008 at 7:20 AM

Thanks for the kind words! 

Yes, I think your understanding of the UserSession class is correct.

The reason I did not put anything else into the Application layer is that it just turned out that I did not really need to do it.  If you look at my other DDD project (, that is exactly what I do.  To answer your previous question, if I was to email interested parties when a project was updated then I would in fact put that coordination code into the application layer.

Aug 5, 2008 at 12:21 PM

I have taken a look at your other project (looks juicy, don't suppose you have a book on it :0) ) and noticed that the Application Services look rather like use case's, would this be a fair point? I like the idea of this. It makes sense for an e-commerce application to have a PlaceOrderService in the application layer.

Aug 8, 2008 at 12:21 AM

That's a great way to think of them, they are actually implementing a use case when you look at them!  I guess you could say that they are also like mini-orchestrations (or even mini synchronous workflow activities), in that they are orchestrating/coordinating the objects of the Domain Model and the various Infrastructure layers to do whatever supports the use case.  Also notice that they are where the Unit of Work instances are created and committed as well.