Loading ...
Sorry, an error occurred while loading the content.
 

RE: [domaindrivendesign] Re: Can we unite application layer and domain services?

Expand Messages
  • randy stafford
    Hi Chris, What you have said here is almost consistent with the prior art (of which there is an appreciable amount), but not quite perfectly consistent. You
    Message 1 of 10 , Jan 17, 2008

      Hi Chris,

       

      What you have said here is almost consistent with the prior art (of which there is an appreciable amount), but not quite perfectly consistent.

       

      You expose the application to the world through application services.  Not only can you build many applications that use the same domain model, you can also build many interfaces to the same application, which is what I would regard your example to demonstrate.

       

      The prior art includes Service Layer, Application Boundary, Eric’s distinction of application services from domain services (pp.106-107), Hexagonal Architecture, and other publications.

       

      Here are some links to previous discussions of this topic in this group:

       

      Like you, I also have to respectfully disagree with Richard’s assertion, though I very much appreciate his intellect and postings here and work on Naked Objects.  The best litmus test for a “true” DDD system that I know of is Eric’s statement on p.75 that DDD requires only a domain layer (in a layered architecture), implementing a domain model.  By that test, what layers (if any) exist above and below the domain layer is not material to a system’s qualification as a DDD system.  I interpret that in a Naked DDD system, there must be no application construct.

       

      However I have found applications to be incredibly important things.  After all, we don’t set out to build domain models in isolation.  Rather, we are commissioned to build applications, and applications include more than domain models.  As Eric says, “there is no meaning of ‘file formats’ in the domain of banking, and there are no business rules involved” (p.107).  That is why application services, forming a Service Layer, defining an Application Boundary, are important.  And note that UI Controllers are outside this boundary layer, acting as clients of the application services.  The layer containing UI Controllers (in the Jacobsonian sense, see http://c2.com/cgi/wiki?WhatsaControllerAnyway) has historically been called the “Application Layer”, which has become confusing since some of its responsibilities moved to the layer of application services with the advent of three-tier architecture (as I tried to describe on http://c2.com/cgi/wiki?FourLayerArchitectureDiscussion), so it might be better to call it the Controller layer now (as much as it galls me as an old Smalltalker to give in to the Jacobsonion connotation of Controller).

       

      Kind Regards,

      Randy

       


      From: domaindrivendesign@yahoogroups.com [mailto: domaindrivendesign@yahoogroups.com ] On Behalf Of Chris Norton
      Sent: Thursday, January 17, 2008 8:06 AM
      To: domaindrivendesign@yahoogroups.com
      Subject: Re: [domaindrivendesign] Re: Can we unite application layer and domain services?

       

      > In a truely DDD system there should be no such thing as an 'Application' construct.

      I disagree. The domain contains those things that model your business:
      services, entities, value objects, etc. You expose the domain to the
      world through services. You can build many applications that use the
      domain. For example, a web application, a batch process, a
      message-queue processor, a web service, a swing application, and so
      on. The contract expressed by the domain remains consistent for all
      consumers.

      -Chris

      On Jan 17, 2008 5:38 AM, Richard Pawson <rpawson@nakedobject s.org> wrote:

      >
      >
      >
      >
      >
      >
      > If I have understood your point correctly, then I agree with you: in a
      > truely DDD system there should be no such thing as an 'Application'
      > construct. All business functionality should lie on the domain objects
      > and their supporting services, which IMO constitute part of the domain
      > layer. (The debate about the split in responsibility between the entity
      > objects and the service objects is orthogonal to your point - though
      > I am strongly in favour of encapsulating as much logic as possible onto
      > the domain objects - see separate thread). The term 'application' is
      > then either just another name for a domain model itself, or it refers
      > to a sub-set of a broader domain model that is made available to a
      > particular group of users (preferably just using permissions
      > management).
      >
      > In a Naked Objects system all we develop are the domain objects and
      > services. Period. The user interface is generated from this
      > dynamically. Your approach of doing the latter with AOP is another
      > valid approach to achieving the same ideal.
      >
      > Richard
      >
      >

    • Peter Ritchie
      Application layer is an Evans term, Service layer is a Folwer term.[1] Domain layer is Evans s term for Fowler s Model layer.[1] [1]
      Message 2 of 10 , Jan 19, 2008
        Application layer is an Evans term, Service layer is a Folwer term.[1]

        Domain layer is Evans's term for Fowler's Model layer.[1]

        [1] http://martinfowler.com/bliki/AnemicDomainModel.html

        --- In domaindrivendesign@yahoogroups.com, "david_torontonian"
        <david_torontonian@...> wrote:
        >
        > Application layer and Service Layer are the same; just two different
        > names.
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.