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

Re: Domain logic is mainly handled in Services?

Expand Messages
  • Richard Pawson
    As you will read elsewhere on this forum, there is no consensus on this. I live in the camp that says: wherever possible push the logic onto the domain
    Message 1 of 14 , Feb 28, 2008
      As you will read elsewhere on this forum, there is no consensus on
      this. I live in the camp that says: wherever possible push the
      logic onto the domain entities, not services. For many designers the
      default position seems to be that logic goes on domain services, but
      to me this is just old-fashioned separation of procedure and data.

      In the Irish government, we built a huge and hugely-complex model
      using DDD principles. We managed to keen 100% of the domain logic on
      the domain entities. There are many services, but their role is
      exclusively to bridge between inside and outside the business
      domain - either because they need to bridge to a technical domain
      (e.g. database, email sending, printing) or to a business domain that
      was outside our control (i.e. legacy system code).

      In a more recent large scale DDD project I did push more domain logic
      onto domain services, but this was for a very specific reason: we
      were making much higher use of interfaces and polymorphism. A
      typical domain entity was implementing up to a dozen domain
      interfaces (they also implemented other non-domain interfaces, but
      that is of no concern here). One such interface was DocumentContext,
      which meant that that domain entity could have scanned documents
      associated with it. Then we had services that could e.g. retrieve
      the most recent Documents associated with that DocumentContext. This
      logic had to be on a domain service, because there was no common root
      for all the entities that implemented DocumentContext. (Although
      that's partly because I'm working in Java: if I was using AOP or a
      language that supported mix-ins or multitple inheritance then other
      options would be available).

      (As an aside: making intensive use of polymorphism like this tends
      to get the database community very upset because you can't implement
      referential integrity at the database level. You are forced to do it
      in the domain model, which is a good thing IMO, but they do get upset
      about it).

      So this is broadly in-line with the previous poster's principle
      about 'put it in a service if there's no obvious domain entity owner'.

      His second point is a little more controversial: that where an
      operation involves two different (domain entity) aggregates then put
      the logic on a domain server. The only cases where I have done this
      are really examples of the first principle. I do not agree with the
      common assertion (not made by him, though) that the logic for
      transferring money between two (internal) accounts must lie in a
      domain service because it doesn't belong in either entity. This is
      plain wrong: there is no problem with having CheckingAccount and
      SavingsAccount inherit from a common AbstractAccount and having a
      method at that level: transferTo(AbstractAccount toAccount, Money
      amount).

      To me, the key lies in interfaces. I strongly favour the pattern of
      breaking up the domain model into large chunks (packages, modules),
      each of which has a set of interfaces and classes. Within a package,
      classes may invoke each others' methods directly, but a class within
      one package may only refer to interfaces in another. (This is quite
      easy to enforce). Once you have that structure, the question of
      whether domain logic can be put on entities or must go on domain
      services becomes a lot clearer: if an interface is implemented by
      classes in different packages then you need to put the logic for
      those methods onto a domain service. But if an interface is only to
      be implemented by classes in the same package (albeit potentially
      different implementations) then put the domain logic into a
      superclass within that package.

      Hope that helps.

      Richard



      --- In domaindrivendesign@yahoogroups.com, "acqy_sunnychen"
      <acqy_sunnychen@...> wrote:
      >
      > Hi kaushik_spock,
      >
      > Thanks for your reply and actually I'm also have the same concept
      > that you have.
      >
      > Exactly according to DDD, there are two kinds of Service, one for
      > Application and another for Domain. What I mentioned here is the
      > Service for Domain, sorry for my careless.
      >
      > Thanks again!
      >
      > --- In domaindrivendesign@yahoogroups.com, "kaushik_spock"
      > <kaushik.spock@> wrote:
      > >
      > > Domain logic belongs in entities and domain layer services. The
      > > services in application layer would not have any domain logic in
      > > them.
      > >
      > > The thumb rule i am trying to use for deciding where logic should
      > > reside is this
      > > - If you can't think of a logical owner(entity) for the behaviour
      > > put it as a service
      > > - If your domain logic affects entities across 2 or more
      > aggregates,
      > > then have the services act as orchestrator which calls methods in
      > > entities that act on themselves and do pieces of the logic
      > > - If your domain logic affects entities only within an aggregate,
      > > then the root of aggregate should act as orchestrator
      > >
      > > However i am very new to DDD and this is my initial thoughts on
      > how
      > > to do it.
      > >
      > > Thanks,
      > > Kaushik
      > >
      > > > The thing that confusing me much is that, which role described
      > in
      > > DDD
      > > > handles the domain logic (or business logic), the Services?
      > > >
      > >
      >
    • Ertugrul Uysal
      This was one of the most useful posts I read, thanks. In the side note you mention about implementing referential integrity in the domain model. Considering
      Message 2 of 14 , Feb 28, 2008
        This was one of the most useful posts I read, thanks. In the "side note" you mention about implementing referential integrity in the domain model. Considering it is a large scale project, (probably with lots of concurrent users and millions of records ending up in database tables) how do you do it? I think it is not a big deal if somehow everything fits in RAM, but it isn't the case, is it?



        ----- Original Message ----
        From: Richard Pawson <rpawson@...>
        To: domaindrivendesign@yahoogroups.com
        Sent: Thursday, February 28, 2008 12:34:14 PM
        Subject: [domaindrivendesign] Re: Domain logic is mainly handled in Services?

        As you will read elsewhere on this forum, there is no consensus on
        this. I live in the camp that says: wherever possible push the
        logic onto the domain entities, not services. For many designers the
        default position seems to be that logic goes on domain services, but
        to me this is just old-fashioned separation of procedure and data.

        In the Irish government, we built a huge and hugely-complex model
        using DDD principles. We managed to keen 100% of the domain logic on
        the domain entities. There are many services, but their role is
        exclusively to bridge between inside and outside the business
        domain - either because they need to bridge to a technical domain
        (e.g. database, email sending, printing) or to a business domain that
        was outside our control (i.e. legacy system code).

        In a more recent large scale DDD project I did push more domain logic
        onto domain services, but this was for a very specific reason: we
        were making much higher use of interfaces and polymorphism. A
        typical domain entity was implementing up to a dozen domain
        interfaces (they also implemented other non-domain interfaces, but
        that is of no concern here). One such interface was DocumentContext,
        which meant that that domain entity could have scanned documents
        associated with it. Then we had services that could e.g. retrieve
        the most recent Documents associated with that DocumentContext. This
        logic had to be on a domain service, because there was no common root
        for all the entities that implemented DocumentContext. (Although
        that's partly because I'm working in Java: if I was using AOP or a
        language that supported mix-ins or multitple inheritance then other
        options would be available).

        (As an aside: making intensive use of polymorphism like this tends
        to get the database community very upset because you can't implement
        referential integrity at the database level. You are forced to do it
        in the domain model, which is a good thing IMO, but they do get upset
        about it).

        So this is broadly in-line with the previous poster's principle
        about 'put it in a service if there's no obvious domain entity owner'.

        His second point is a little more controversial: that where an
        operation involves two different (domain entity) aggregates then put
        the logic on a domain server. The only cases where I have done this
        are really examples of the first principle. I do not agree with the
        common assertion (not made by him, though) that the logic for
        transferring money between two (internal) accounts must lie in a
        domain service because it doesn't belong in either entity. This is
        plain wrong: there is no problem with having CheckingAccount and
        SavingsAccount inherit from a common AbstractAccount and having a
        method at that level: transferTo(AbstractAccount toAccount, Money
        amount).

        To me, the key lies in interfaces. I strongly favour the pattern of
        breaking up the domain model into large chunks (packages, modules),
        each of which has a set of interfaces and classes. Within a package,
        classes may invoke each others' methods directly, but a class within
        one package may only refer to interfaces in another. (This is quite
        easy to enforce). Once you have that structure, the question of
        whether domain logic can be put on entities or must go on domain
        services becomes a lot clearer: if an interface is implemented by
        classes in different packages then you need to put the logic for
        those methods onto a domain service. But if an interface is only to
        be implemented by classes in the same package (albeit potentially
        different implementations) then put the domain logic into a
        superclass within that package.

        Hope that helps.

        Richard



        --- In domaindrivendesign@yahoogroups.com, "acqy_sunnychen"
        <acqy_sunnychen@...> wrote:
        >
        > Hi kaushik_spock,
        >
        > Thanks for your reply and actually I'm also have the same concept
        > that you have.
        >
        > Exactly according to DDD, there are two kinds of Service, one for
        > Application and another for Domain. What I mentioned here is the
        > Service for Domain, sorry for my careless.
        >
        > Thanks again!
        >
        > --- In domaindrivendesign@yahoogroups.com, "kaushik_spock"
        > <kaushik.spock@> wrote:
        > >
        > > Domain logic belongs in entities and domain layer services. The
        > > services in application layer would not have any domain logic in
        > > them.
        > >
        > > The thumb rule i am trying to use for deciding where logic should
        > > reside is this
        > > - If you can't think of a logical owner(entity) for the behaviour
        > > put it as a service
        > > - If your domain logic affects entities across 2 or more
        > aggregates,
        > > then have the services act as orchestrator which calls methods in
        > > entities that act on themselves and do pieces of the logic
        > > - If your domain logic affects entities only within an aggregate,
        > > then the root of aggregate should act as orchestrator
        > >
        > > However i am very new to DDD and this is my initial thoughts on
        > how
        > > to do it.
        > >
        > > Thanks,
        > > Kaushik
        > >
        > > > The thing that confusing me much is that, which role described
        > in
        > > DDD
        > > > handles the domain logic (or business logic), the Services?
        > > >
        > >
        >





        Yahoo! Groups Links








        ____________________________________________________________________________________
        Be a better friend, newshound, and
        know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
      • adam wolf
        Richard, Do you include in your entity packaging the repositories for your entities or do you put them in a separate package. I know the interfaces for the
        Message 3 of 14 , Feb 28, 2008

          Richard, Do you include in your entity packaging the repositories for your entities or do you put them in a separate package. I know the interfaces for the repositories are packaged with the entities but was wondering if you found value in separating the implementation of the repositories from the interface. I have a feeling from your post that you would package them with the entities and your DAO are always package separately.
           
           
          Adam

           


          To: domaindrivendesign@yahoogroups.com
          From: rpawson@...
          Date: Thu, 28 Feb 2008 10:34:14 +0000
          Subject: [domaindrivendesign] Re: Domain logic is mainly handled in Services?

          As you will read elsewhere on this forum, there is no consensus on
          this. I live in the camp that says: wherever possible push the
          logic onto the domain entities, not services. For many designers the
          default position seems to be that logic goes on domain services, but
          to me this is just old-fashioned separation of procedure and data.

          In the Irish government, we built a huge and hugely-complex model
          using DDD principles. We managed to keen 100% of the domain logic on
          the domain entities. There are many services, but their role is
          exclusively to bridge between inside and outside the business
          domain - either because they need to bridge to a technical domain
          (e.g. database, email sending, printing) or to a business domain that
          was outside our control (i.e. legacy system code).

          In a more recent large scale DDD project I did push more domain logic
          onto domain services, but this was for a very specific reason: we
          were making much higher use of interfaces and polymorphism. A
          typical domain entity was implementing up to a dozen domain
          interfaces (they also implemented other non-domain interfaces, but
          that is of no concern here). One such interface was DocumentContext,
          which meant that that domain entity could have scanned documents
          associated with it. Then we had services that could e.g. retrieve
          the most recent Documents associated with that DocumentContext. This
          logic had to be on a domain service, because there was no common root
          for all the entities that implemented DocumentContext. (Although
          that's partly because I'm working in Java: if I was using AOP or a
          language that supported mix-ins or multitple inheritance then other
          options would be available).

          (As an aside: making intensive use of polymorphism like this tends
          to get the database community very upset because you can't implement
          referential integrity at the database level. You are forced to do it
          in the domain model, which is a good thing IMO, but they do get upset
          about it).

          So this is broadly in-line with the previous poster's principle
          about 'put it in a service if there's no obvious domain entity owner'.

          His second point is a little more controversial: that where an
          operation involves two different (domain entity) aggregates then put
          the logic on a domain server. The only cases where I have done this
          are really examples of the first principle. I do not agree with the
          common assertion (not made by him, though) that the logic for
          transferring money between two (internal) accounts must lie in a
          domain service because it doesn't belong in either entity. This is
          plain wrong: there is no problem with having CheckingAccount and
          SavingsAccount inherit from a common AbstractAccount and having a
          method at that level: transferTo(Abstract Account toAccount, Money
          amount).

          To me, the key lies in interfaces. I strongly favour the pattern of
          breaking up the domain model into large chunks (packages, modules),
          each of which has a set of interfaces and classes. Within a package,
          classes may invoke each others' methods directly, but a class within
          one package may only refer to interfaces in another. (This is quite
          easy to enforce). Once you have that structure, the question of
          whether domain logic can be put on entities or must go on domain
          services becomes a lot clearer: if an interface is implemented by
          classes in different packages then you need to put the logic for
          those methods onto a domain service. But if an interface is only to
          be implemented by classes in the same package (albeit potentially
          different implementations) then put the domain logic into a
          superclass within that package.

          Hope that helps.

          Richard

          --- In domaindrivendesign@ yahoogroups. com, "acqy_sunnychen"
          <acqy_sunnychen@ ...> wrote:
          >
          > Hi kaushik_spock,
          >
          > Thanks for your reply and actually I'm also have the same concept
          > that you have.
          >
          > Exactly according to DDD, there are two kinds of Service, one for
          > Application and another for Domain. What I mentioned here is the
          > Service for Domain, sorry for my careless.
          >
          > Thanks again!
          >
          > --- In domaindrivendesign@ yahoogroups. com, "kaushik_spock"
          > <kaushik.spock@ > wrote:
          > >
          > > Domain logic belongs in entities and domain layer services. The
          > > services in application layer would not have any domain logic in
          > > them.
          > >
          > > The thumb rule i am trying to use for deciding where logic should
          > > reside is this
          > > - If you can't think of a logical owner(entity) for the behaviour
          > > put it as a service
          > > - If your domain logic affects entities across 2 or more
          > aggregates,
          > > then have the services act as orchestrator which calls methods in
          > > entities that act on themselves and do pieces of the logic
          > > - If your domain logic affects entities only within an aggregate,
          > > then the root of aggregate should act as orchestrator
          > >
          > > However i am very new to DDD and this is my initial thoughts on
          > how
          > > to do it.
          > >
          > > Thanks,
          > > Kaushik
          > >
          > > > The thing that confusing me much is that, which role described
          > in
          > > DDD
          > > > handles the domain logic (or business logic), the Services?
          > > >
          > >
          >


        • acqy_sunnychen
          Haha! This is also the most helpful post I ve read. Thank you very much Richard!!! As for me, I ll continue with my work, by refactoring according to DDD......
          Message 4 of 14 , Feb 28, 2008
            Haha!

            This is also the most helpful post I've read. Thank you very much
            Richard!!!

            As for me, I'll continue with my work, by refactoring according to
            DDD......

            --- In domaindrivendesign@yahoogroups.com, "Richard Pawson"
            <rpawson@...> wrote:
            >
            > As you will read elsewhere on this forum, there is no consensus on
            > this. I live in the camp that says: wherever possible push the
            > logic onto the domain entities, not services. For many designers
            the
            > default position seems to be that logic goes on domain services,
            but
            > to me this is just old-fashioned separation of procedure and data.
            >
            > In the Irish government, we built a huge and hugely-complex model
            > using DDD principles. We managed to keen 100% of the domain logic
            on
            > the domain entities. There are many services, but their role is
            > exclusively to bridge between inside and outside the business
            > domain - either because they need to bridge to a technical
            domain
            > (e.g. database, email sending, printing) or to a business domain
            that
            > was outside our control (i.e. legacy system code).
            >
            > In a more recent large scale DDD project I did push more domain
            logic
            > onto domain services, but this was for a very specific reason: we
            > were making much higher use of interfaces and polymorphism. A
            > typical domain entity was implementing up to a dozen domain
            > interfaces (they also implemented other non-domain interfaces, but
            > that is of no concern here). One such interface was
            DocumentContext,
            > which meant that that domain entity could have scanned documents
            > associated with it. Then we had services that could e.g. retrieve
            > the most recent Documents associated with that DocumentContext.
            This
            > logic had to be on a domain service, because there was no common
            root
            > for all the entities that implemented DocumentContext. (Although
            > that's partly because I'm working in Java: if I was using AOP or
            a
            > language that supported mix-ins or multitple inheritance then
            other
            > options would be available).
            >
            > (As an aside: making intensive use of polymorphism like this
            tends
            > to get the database community very upset because you can't
            implement
            > referential integrity at the database level. You are forced to do
            it
            > in the domain model, which is a good thing IMO, but they do get
            upset
            > about it).
            >
            > So this is broadly in-line with the previous poster's principle
            > about 'put it in a service if there's no obvious domain entity
            owner'.
            >
            > His second point is a little more controversial: that where an
            > operation involves two different (domain entity) aggregates then
            put
            > the logic on a domain server. The only cases where I have done
            this
            > are really examples of the first principle. I do not agree with
            the
            > common assertion (not made by him, though) that the logic for
            > transferring money between two (internal) accounts must lie in a
            > domain service because it doesn't belong in either entity. This
            is
            > plain wrong: there is no problem with having CheckingAccount and
            > SavingsAccount inherit from a common AbstractAccount and having a
            > method at that level: transferTo(AbstractAccount toAccount, Money
            > amount).
            >
            > To me, the key lies in interfaces. I strongly favour the pattern
            of
            > breaking up the domain model into large chunks (packages,
            modules),
            > each of which has a set of interfaces and classes. Within a
            package,
            > classes may invoke each others' methods directly, but a class
            within
            > one package may only refer to interfaces in another. (This is
            quite
            > easy to enforce). Once you have that structure, the question of
            > whether domain logic can be put on entities or must go on domain
            > services becomes a lot clearer: if an interface is implemented by
            > classes in different packages then you need to put the logic for
            > those methods onto a domain service. But if an interface is only
            to
            > be implemented by classes in the same package (albeit potentially
            > different implementations) then put the domain logic into a
            > superclass within that package.
            >
            > Hope that helps.
            >
            > Richard
            >
            >
            >
            > --- In domaindrivendesign@yahoogroups.com, "acqy_sunnychen"
            > <acqy_sunnychen@> wrote:
            > >
            > > Hi kaushik_spock,
            > >
            > > Thanks for your reply and actually I'm also have the same
            concept
            > > that you have.
            > >
            > > Exactly according to DDD, there are two kinds of Service, one
            for
            > > Application and another for Domain. What I mentioned here is the
            > > Service for Domain, sorry for my careless.
            > >
            > > Thanks again!
            > >
            > > --- In domaindrivendesign@yahoogroups.com, "kaushik_spock"
            > > <kaushik.spock@> wrote:
            > > >
            > > > Domain logic belongs in entities and domain layer services.
            The
            > > > services in application layer would not have any domain logic
            in
            > > > them.
            > > >
            > > > The thumb rule i am trying to use for deciding where logic
            should
            > > > reside is this
            > > > - If you can't think of a logical owner(entity) for the
            behaviour
            > > > put it as a service
            > > > - If your domain logic affects entities across 2 or more
            > > aggregates,
            > > > then have the services act as orchestrator which calls methods
            in
            > > > entities that act on themselves and do pieces of the logic
            > > > - If your domain logic affects entities only within an
            aggregate,
            > > > then the root of aggregate should act as orchestrator
            > > >
            > > > However i am very new to DDD and this is my initial thoughts
            on
            > > how
            > > > to do it.
            > > >
            > > > Thanks,
            > > > Kaushik
            > > >
            > > > > The thing that confusing me much is that, which role
            described
            > > in
            > > > DDD
            > > > > handles the domain logic (or business logic), the Services?
            > > > >
            > > >
            > >
            >
          • Richard Pawson
            Adam I include the repository interface (e.g. CustomerRepository) in the package, as you ve guessed. But I tend to put the implementation(s) of that repository
            Message 5 of 14 , Feb 29, 2008
              Adam

              I include the repository interface (e.g. CustomerRepository) in the
              package, as you've guessed. But I tend to put the implementation(s) of
              that repository elsewhere. So I commonly write a
              CustomerRepositoryInMemory implementation for prototyping, and then a
              CustomerRepositoryHibernate for the real thing. The former I tend to
              put in a separate project, together with the prototyping fixtures; the
              latter I tend to put in a package with the other Hibenrate repositories.

              Another useful trick. Sometimes I split the definition of
              CustomerRepository into two separate interfaces, one inheriting from
              the other. The super interface defines methods that are accessible
              from other packages (i.e. things that need to get hold of or use
              Customers) and this is put into the xx.xx.customer package. The sub-
              interface defines additional methods that are accessible only within
              the customer package )(i.e. in xx.xx.customer.impl ). The
              implementations implement all of them.

              To address your last point I don't use DAOs. As posted elsehere, I use
              Naked Objects and there is just no need for them. The framework does
              all the basic CRUD and navigation transparently.

              Richard


              --- In domaindrivendesign@yahoogroups.com, adam wolf <adamjwolf@...>
              wrote:
              >
              > Richard, Do you include in your entity packaging the repositories for
              your entities or do you put them in a separate package. I know the
              interfaces for the repositories are packaged with the entities but was
              wondering if you found value in separating the implementation of the
              repositories from the interface. I have a feeling from your post that
              you would package them with the entities and your DAO are always
              package separately.
            • Richard Pawson
              There s no issue with scaleability in giving the domain model responsibility for maintaining the integrity of the model. The issue for most organisations is
              Message 6 of 14 , Feb 29, 2008
                There's no issue with scaleability in giving the domain model
                responsibility for maintaining the integrity of the model. The issue
                for most organisations is that they want to have the same database
                accessible (both for read and write) by other applications that aren't
                accessing it through the DOM. Then it is understandable that they want
                to enforce referential integrity at the database level.

                My view is that we are gradually moving away from the model of multiple
                applications having direct write-access to a shared database, to a
                situation where all write-accesses to the database need to go through
                some sort of shared service, whether web-service or other, where the
                interface to that service is written in domain terms.

                BTW, I am not a database expert at all. But I am surprised at the
                number of conversations I've had recently with people who are real
                database experts where they concur that database-enforced referential
                integrity isis not as important (or feasible) a proposition as it was
                10 years ago.

                Richard

                --- In domaindrivendesign@yahoogroups.com, Ertugrul Uysal
                <ertugrul_uysal@...> wrote:
                >
                > This was one of the most useful posts I read, thanks. In the "side
                note" you mention about implementing referential integrity in the
                domain model. Considering it is a large scale project, (probably with
                lots of concurrent users and millions of records ending up in database
                tables) how do you do it? I think it is not a big deal if somehow
                everything fits in RAM, but it isn't the case, is it?
              • Giovanni Cuccu
                This is a bit off-topic but I think it could be interesting. In my career I faced more than once a situation where the build of new application had the
                Message 7 of 14 , Feb 29, 2008
                  This is a bit off-topic but I think it could be interesting.
                  In my career I faced more than once a situation where the build of new
                  application had the constraint to use an already established database
                  (which means both RDMS software and database design).
                  One project was a migration from an Oracle-Cobol application to a
                  "brand new" Oracle-Java application. the contraints were in the cobol
                  code and also because of that the transition has been really painful.
                  So my suggestion is: data (RDBMS platform and schema) is here to stay
                  while code (language and classes) are more volatile so put your
                  constraints where you can reuse them.
                  Giovanni


                  On Fri, Feb 29, 2008 at 9:53 AM, Richard Pawson
                  <rpawson@...> wrote:

                  > BTW, I am not a database expert at all. But I am surprised at the
                  > number of conversations I've had recently with people who are real
                  > database experts where they concur that database-enforced referential
                  > integrity isis not as important (or feasible) a proposition as it was
                  > 10 years ago.
                  >
                  > Richard
                  >
                  > --- In domaindrivendesign@yahoogroups.com, Ertugrul Uysal
                  > <ertugrul_uysal@...> wrote:
                  > >
                  > > This was one of the most useful posts I read, thanks. In the "side
                  > note" you mention about implementing referential integrity in the
                  > domain model. Considering it is a large scale project, (probably with
                  > lots of concurrent users and millions of records ending up in database
                  > tables) how do you do it? I think it is not a big deal if somehow
                  > everything fits in RAM, but it isn't the case, is it?
                  >
                  >



                  --
                  --------------------------------------------------------------------
                  "You don't know the power of dark side" - Darth Vader
                • david_torontonian
                  Thanks Richard! You explained it very well. ... aggregates,
                  Message 8 of 14 , Feb 29, 2008
                    Thanks Richard! You explained it very well.

                    --- In domaindrivendesign@yahoogroups.com, "kaushik_spock"
                    <kaushik.spock@...> wrote:
                    >
                    > Domain logic belongs in entities and domain layer services. The
                    > services in application layer would not have any domain logic in
                    > them.
                    >
                    > The thumb rule i am trying to use for deciding where logic should
                    > reside is this
                    > - If you can't think of a logical owner(entity) for the behaviour
                    > put it as a service
                    > - If your domain logic affects entities across 2 or more
                    aggregates,
                    > then have the services act as orchestrator which calls methods in
                    > entities that act on themselves and do pieces of the logic
                    > - If your domain logic affects entities only within an aggregate,
                    > then the root of aggregate should act as orchestrator
                    >
                    > However i am very new to DDD and this is my initial thoughts on how
                    > to do it.
                    >
                    > Thanks,
                    > Kaushik
                    >
                    > > The thing that confusing me much is that, which role described in
                    > DDD
                    > > handles the domain logic (or business logic), the Services?
                    > >
                    >
                  • arioch022000
                    This is a really interesting topic, and there have been a lot of good comments. However, no one has brought up the issue concerning the reality that the model
                    Message 9 of 14 , Mar 1, 2008

                      This is a really interesting topic, and there have been a lot of good comments. However, no one has brought up the issue concerning the reality that the model for a distributed system often needs to be very different from the model used for a system that's only going to be deployed on one machine. Often there is a requirement for domain logic to be packaged into one or more services that can be exposed in an enterprise, interoperable way. I'm seeing many clients of mine turn to SOA as an answer, not just vanilla OO solutions.

                      There are many benefits to SOA, implemented properly, SOA can deliver platform interoperability, document centric assets (services and their operations) that can be governed, versioned, and managed on a large scale, standard based messaging (a la SWIFT, IFX, etc.), the list goes on. Unfortunately, SOA means that the platform of a service client cannot be guaranteed. The domain objects often end up being the product of XML generation techniques, have very little domain logic, and are simply data carriers.

                      While I agree that conceptually domain logic should typically belong on the domain entity, this is difficult to achieve while guaranteeing platform interoperability. In an SOA one typically ends up with the procedural like mechanism of passing data to operations. And I'm seeing some form of SOA being implemented in most large scale solutions I come across in typical industries like banks, telecommunications, financial services, et cetera. I hope I'm not coming off as one of those SOA zealots, I'm simply trying to point out that this stuff is very real, and has a very real impact on Domain Driven Design.

                      I've still managed to follow many domain driven design principles on SOA projects, but some sacrifices were required. I would be interested to hear any other comments or experiences on using DDD and SOA together.

                       

                      --- In domaindrivendesign@yahoogroups.com, "david_torontonian" <david_torontonian@...> wrote:
                      >
                      > Thanks Richard! You explained it very well.
                      >
                      > --- In domaindrivendesign@yahoogroups.com, "kaushik_spock"
                      > kaushik.spock@ wrote:
                      > >
                      > > Domain logic belongs in entities and domain layer services. The
                      > > services in application layer would not have any domain logic in
                      > > them.
                      > >
                      > > The thumb rule i am trying to use for deciding where logic should
                      > > reside is this
                      > > - If you can't think of a logical owner(entity) for the behaviour
                      > > put it as a service
                      > > - If your domain logic affects entities across 2 or more
                      > aggregates,
                      > > then have the services act as orchestrator which calls methods in
                      > > entities that act on themselves and do pieces of the logic
                      > > - If your domain logic affects entities only within an aggregate,
                      > > then the root of aggregate should act as orchestrator
                      > >
                      > > However i am very new to DDD and this is my initial thoughts on how
                      > > to do it.
                      > >
                      > > Thanks,
                      > > Kaushik
                      > >
                      > > > The thing that confusing me much is that, which role described in
                      > > DDD
                      > > > handles the domain logic (or business logic), the Services?
                      > > >
                      > >
                      >
                    • Udi Dahan
                      ... the model used for a system that s only going to be deployed on one machine. I think it would be more accurate to say that the design of a distributed
                      Message 10 of 14 , Mar 3, 2008

                        > the model for a distributed system often needs to be

                        very different from the model used for a system that's only going to be deployed on one machine.

                         

                        I think it would be more accurate to say that the design of a distributed system should be different from one deployed on a single machine.

                         

                        > Often there is a requirement for domain logic to be

                        packaged into one or more services that can be exposed in an enterprise, interoperable way

                         

                        Actually, I think that that’s your interpretation of the core requirement that external systems integrate with your system.

                         

                        > Unfortunately, SOA means that the platform of a service

                        client cannot be guaranteed

                         

                        Why unfortunately? And, regardless of SOA, even 3/N-Tier didn’t necessarily assume the platform of the client.

                         

                        > The domain objects often end up being the product of

                        XML generation techniques, have very little domain logic, and are simply data carriers.

                         

                        The fact that SOA makes heavy use of messaging and the data transfer object pattern does not negate the domain model pattern. It’s just that the client does not interact directly with persistent domain objects, although there’s no (SOA) reason not to use them in the service implementation.

                         

                        > … has a very real impact on Domain Driven Design.

                         

                        Not in my experience. Not if you have chunky business services. Not if you do SOA right. Business services encapsulate a domain – DDD provides a great deal of value inside business services.

                         

                        Hope that helps.

                         

                        > Re: Domain logic is mainly

                        handled in Services?

                        > Posted by:

                        "arioch022000" Thomasjeffreyandersontwin@...   arioch022000

                        > Mon Mar 3, 2008 12:20 am

                        (PST)

                         

                         

                        --
                        Udi Dahan - The Software Simplist
                        .NET Development Expert & SOA Specialist

                        Udi Dahan's Blog


                        No virus found in this outgoing message.
                        Checked by AVG Free Edition.
                        Version: 7.5.516 / Virus Database: 269.21.3/1307 - Release Date: 02/03/2008 15:59

                      • Alberto Brandolini
                        Hi, I think that SOA is an architectural perspective that doesn t care about how the domains are implemented inside the applications. SOA provides a set of
                        Message 11 of 14 , Mar 4, 2008
                          Hi,

                          I think that SOA is an architectural perspective that "doesn't care"
                          about how the domains are implemented inside the applications.
                          SOA provides a set of instruments to define a loosely coupled "glue"
                          between different applications. There is some sort of "domain" on the
                          communication bus, but it doesn't have to be the domain of your
                          application.
                          1) if it's the projection of an XML representation it tends to be anemic
                          2) it can be shared with Legacy apps
                          3) as DDD says, a model fits one purpose while a model shared on the
                          communication bus will be used for many purposes, but too many forces
                          acting on one domain model will force it to paralysis rather than
                          evolution.

                          DDD is a key tool to model complex domains and can be very powerful in
                          a SOA context, eventually tied with an anti-corruption layer or
                          similar boundary patterns. SOA does not say that application must be
                          data centric or XML centric. This is just often the easiest solution
                          found for simple domains, driven by vendors and tools. Not necessarily
                          the better.

                          best regards

                          Alberto


                          --- In domaindrivendesign@yahoogroups.com, "arioch022000"
                          <Thomasjeffreyandersontwin@...> wrote:
                          >
                          >
                          > This is a really interesting topic, and there have been a lot of good
                          > comments. However, no one has brought up the issue concerning the
                          > reality that the model for a distributed system often needs to be very
                          > different from the model used for a system that's only going to be
                          > deployed on one machine. Often there is a requirement for domain logic
                          > to be packaged into one or more services that can be exposed in an
                          > enterprise, interoperable way. I'm seeing many clients of mine turn to
                          > SOA as an answer, not just vanilla OO solutions.
                          >
                          > There are many benefits to SOA, implemented properly, SOA can deliver
                          > platform interoperability, document centric assets (services and their
                          > operations) that can be governed, versioned, and managed on a large
                          > scale, standard based messaging (a la SWIFT, IFX, etc.), the list goes
                          > on. Unfortunately, SOA means that the platform of a service client
                          > cannot be guaranteed. The domain objects often end up being the product
                          > of XML generation techniques, have very little domain logic, and are
                          > simply data carriers.
                          >
                          > While I agree that conceptually domain logic should typically belong on
                          > the domain entity, this is difficult to achieve while guaranteeing
                          > platform interoperability. In an SOA one typically ends up with the
                          > procedural like mechanism of passing data to operations. And I'm seeing
                          > some form of SOA being implemented in most large scale solutions I come
                          > across in typical industries like banks, telecommunications, financial
                          > services, et cetera. I hope I'm not coming off as one of those SOA
                          > zealots, I'm simply trying to point out that this stuff is very real,
                          > and has a very real impact on Domain Driven Design.
                          >
                          > I've still managed to follow many domain driven design principles on SOA
                          > projects, but some sacrifices were required. I would be interested to
                          > hear any other comments or experiences on using DDD and SOA together.
                          >
                          >
                          > --- In domaindrivendesign@yahoogroups.com, "david_torontonian"
                          > <david_torontonian@> wrote:
                          > >
                          > > Thanks Richard! You explained it very well.
                          > >
                          > > --- In domaindrivendesign@yahoogroups.com, "kaushik_spock"
                          > > kaushik.spock@ wrote:
                          > > >
                          > > > Domain logic belongs in entities and domain layer services. The
                          > > > services in application layer would not have any domain logic in
                          > > > them.
                          > > >
                          > > > The thumb rule i am trying to use for deciding where logic should
                          > > > reside is this
                          > > > - If you can't think of a logical owner(entity) for the behaviour
                          > > > put it as a service
                          > > > - If your domain logic affects entities across 2 or more
                          > > aggregates,
                          > > > then have the services act as orchestrator which calls methods in
                          > > > entities that act on themselves and do pieces of the logic
                          > > > - If your domain logic affects entities only within an aggregate,
                          > > > then the root of aggregate should act as orchestrator
                          > > >
                          > > > However i am very new to DDD and this is my initial thoughts on how
                          > > > to do it.
                          > > >
                          > > > Thanks,
                          > > > Kaushik
                          > > >
                          > > > > The thing that confusing me much is that, which role described in
                          > > > DDD
                          > > > > handles the domain logic (or business logic), the Services?
                          > > > >
                          > > >
                          > >
                          >
                        Your message has been successfully submitted and would be delivered to recipients shortly.