There you go. That's indeed a far better
separation of concerns.
One last thing: I would expect the
getCustomer on the application layer to actually grab the customer from the
CustomerRepository: I wouldn't expect another service-thingie; I wouldn't know
what you would put in there in addition to what's already in the repository and the
application layer itself.
Pascal.
P.S. Actually, having an A-ha moment which
*is* referring to that popular 80's group isn't all that bad either. Now where
did I store "Take on me.mp3"? ;)
--- In domaindrivendesign <at> yahoogroups.com, "elbandit33" <scott <at> ...> wrote:
>
>
> Of course yes, so something like this would be more ideal:~
>
> ' Application Layer
> Public Shared Function getCustomer(ByVal CustomerID As Long) As
> Model.Customer
> ' This then calls the Domain Service
> Return Model.CustomerService.getCustomer(CustomerID)
> End Function
>
> ' Infrastructure.Web.UI
> Public Shared Function getLoggedCustomer() As Model.Customer
>
> Dim aCustomer As Model.Customer
> Dim CustomerID As Long = HttpContext.Current.User.Identity.Name
>
> If HttpContext.Current.Items.Contains("Customer") Then
>
aCustomer =
> CType(HttpContext.Current.Items("Customer"), Model.Customer)
> Else
> ' Calls the application layer. The Application Layer
> is a thin layer that defines the API of the application
> aCustomer =
> Application.AppCustomerService.getCustomer(CustomerID)
> HttpContext.Current.Items.Add("Customer", aCustomer)
> End If
>
> Return aCustomer
>
> End Function
>
> This then satisfys the definition of the application layer :
>
> "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."
>
> If my application ever had the requirement to log all access to the
> Customer files then I could amend my Application layer o something like:
>
> ' Application Layer
> Public Shared Function getCustomer(ByVal CustomerID As Long) As
> Model.Customer
>
> ' Log the request
> infrastructure.logRequest(String.Format("Customer: {0}",
> CustomerID))
>
> ' Calls the Domain Service
> Return Model.CustomerService.getCustomer(CustomerID)
> End Function
>
> The Application would then be unaware of any UI and so I could use a
> windows form.
>
> Thanks I have just got to
the Ah-ha moment (not the popular 80's group).
>
> Scott
>
> --- In domaindrivendesign <at> yahoogroups.com, "Pascal Lindelauf"
> pascal <at> wrote:
> >
> >
> > Thisis getting architecturally smelly. The way I see the logical
> > layering is as follows:
> >
> > * At the very bottom there's your resources, like the
> > database, external services etc.
> > * On top of that sits the domain layer, which contains (1) the
> > repositories for accessing the resources in the layer below and (2)
> > the domain model. The domain model represents the "business
> > model" if you like for this application. It's completely
> > technology agnostic (core DDD principle)
&g
t; > * Now you want the domain model to be accessible from the
> > outside, e.g. by users through a user interface. You can build a
> > user interface layer directly on top of your domain layer, but then
> > you'll have all the repository-access logic and transaction
> > logic in the user interface, which could be considered a bit of a
> > burden on the user interface layer developers. In that case it is
> > common to place an application layer between the user interface layer
> > and the domain layer to make life easy for the UI developer. But
> > what is crucial is that UI-specific concepts remain the UI layer and
> > *not* in the application layer. HttpContext is a web concept (so
> > specific
to the UI you chose) and is therefore not a concept you
> > would want to be aware of in your application layer. Think of it
> > this way: you should actually be able to switch over to a completely
> > different UI technology (e.g. windows forms app or some
> > voice-controlled interface) while still using the exact same
> > application layer.
> >
> > So in case of moffdub's example: I wouldn't want an Application
> > Service (assuming you mean a service in the application layer) to be
> > dependent on an infrastructure service. Instead, have the UI layer
> > extract all the data from the HttpContext and use that as input to the
> > application layer services.
> >
> > Pas
cal
> >
> >
> > --- In domaindrivendesign <at> yahoogroups.com, "moffdub" moffdub <at>
> > wrote:
> > >
> > > Since HttpContext is more of a platform/technical detail, I would
> make
> > > this an Infrastructure Service that is called by some Application
> > Service.
> > >
> > > --- In domaindrivendesign <at> yahoogroups.com, "elbandit33" scott <at>
> wrote:
> > > >
> > > >
> > > > So if I am using my Domain Model and Domain Services in a web
> > > > application can my application layer have access to the
> HttpContext
> > so
> > > > that I can store frequently used items that I want to be around
&g
t; for
> > the
> > > > length for the request?
> > > >
> > > > e.g. Below I store the Customer in the HttpContext.Current.Items
> > > > property because many controls on the same page may access the
> > Logged In
> > > > Customer in the same request:
> > > >
> > > > Public Shared Function getLoggedCustomer() As Model.Customer
> > > >
> > > > Dim aCustomer As Model.Customer
> > > > Diml CustomerID As Long =
> > HttpContext.Current.User.Identity.Name
> > > >
> > > > If HttpContext.Current.Items.Contains("Customer") Then
> > > > aCustomer =
> > CType(HttpContext.C
urrent.Items("Customer"),
> > > > Model.Customer)
> > > > Else
> > > > aCustomer =
> > Model.CustomerService.getCustomer(CustomerID)
> > > >
> > > > HttpContext.Current.Items.Add("Customer", aCustomer)
> > > > End If
> > > >
> > > > Return aCustomer
> > > >
> > > > End Function
> > > >
> > > > Would this be a correct use of the Application Layer? Or should I
> > > > delegate the work of storing the Customer object in some sort of
> web
> > > > infrastructure layer?
> > > >
> > > > Thanks for your help
> > > > Scott
>
> > >
> > > > --- In domaindrivendesign <at> yahoogroups.com, John Roth <JohnRoth1 <at> >
> > > > wrote:
> > > > >
> > > > > Yes. In fact, the definition in the DDD book simply
> > > > > echos the definition of the Application Layer used
> > > > > by a number of other authors.
> > > > >
> > > > > Distinguishing between the two layers is not easy
> > > > > unless you have two or more _different_
> > > > > application layers that both use the same domain
> > > > > layer for different purposes.
> > > > >
> > > > > John Roth
> > > > >
> &
gt; > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "elbandit33" scott <at>
> > > > > To: domaindrivendesign <at> yahoogroups.com
> > > > > Sent: Wednesday, July 30, 2008 8:59 AM
> > > > > Subject: [domaindrivendesign] Role of the Application Layer in
> DDD
> > > > >
> > > > >
> > > > > 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 sta
te of the business objects, but it can hold
> > > > > the state of an application task progress."
> > > > >
> > > > > For an E-Commerce type application would the Application Layer
> > have
> > > > > methods similar to these below:
> > > > >
> > > > >
> > > > > Public Shared SubPlaceOrder(BasketID as String)
> > > > >
> > > > > ' Call domain service
> > > > > Dim aBasket as Basket = BasketService.GetBasket(BasketID )
> > > > >
> > > > > Dim anOrder as Order = OrderService.CreateOrder(aBasket)
> > > > >
> > > > > ' Call infrastructu
re service
> > > > > infrastructure.sendOrderConfirmationEmail(anOrder)
> > > > >
> > > > > End Sub
> > > > >
> > > > > Public Shared Function getProductsByCategory(ID as integer) as
> > List
> > > > > (Of Products)
> > > > >
> > > > > Return ProductService.getProductsByCategory(ID)
> > > > >
> > > > > End Function
> > > > >
> > > > > Thanks
> > > > > Scott
> > > > >
> > > >
> > >
> >
>
__._,_.___
__,_._,___
RSS Feed