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

Re: [domaindrivendesign] Re: Accounts and Members

Expand Messages
  • Farhan Kazmi
    I think you should question the value of the having the Account to Member relationship. Maybe you should reverse the relationship and make each Member
    Message 1 of 22 , Sep 28, 2006
      I think you should question the value of the having the Account to Member relationship.  Maybe you should reverse the relationship and make each Member associated with an Account
       
      On 9/28/06, andrewryan1906 <andrew1906@...
      > wrote:

      Richard,

      I struggled with this a lot in the beginning. It seems like, in a
      data driven app, so much functionality relates to repositories that
      pulling them all out into services would leave you with an anemic
      domain model and transaction scripts. But personally, I think
      injecting the idea of a repository into a domain object is evil.
      This is IMHO. Domain objects shoudl only be able to know about or do
      things relevant to their existence in a domain - the idea that a
      domain object should even know there exists a repository of other
      domain objects is, (again IMHO), against DDD.

      Any operation that requires accessing a repository should
      automatically be a domain service. That service may call domain
      model methods ONCE ITS GOTTEN THE ITEMS FROM THE DOMAIN.

      To give you a real world example, I have a class called Currency and
      a value object (struct) called Money. I wanted to implement a method
      called:

      Currency.Convert( Money moneyToConvert )

      Since Money has a Currency reference, I would essentially be
      converting Money.Currency to the Currency. The problem? I have to
      access the ExchangeRateHistory repository to do this.

      So, you're tempted to use the very sexy Dependency Injection
      princple to get the ExchangeRateHistoryRepository class into the
      Currency class and make it happen, right? But that would definitely
      be the path to the dark side.

      Why? Because your domain model isn't pure anymore. The concept of a
      Currency has been poluted with another concern - persistence. The
      fact that is IoC makes it better, but still not great. Put another
      way - could I pick that domain object up and use it in a completely
      different application? Once, for instance, that didn't have
      repositories, but wanted to pass in the ExchangeRateHistory as an
      XML string or an IDictionary? No.... b/c my class is coupled to the
      idea of a repository. The RIGHT way to do it is:

      Currency.Convert( Money money, decimal exchangeRate );

      Then have a service called CurrencyService that looks up the
      appropriate exchange rate and passes it to the domain object, WHICH
      DOES ALL OF THE WORK. This domain object CAN be used in difference
      apps, b/c the core work of converting from one currency to another
      IS part of the domain model.

      Back to your example - you need an AccountService with a
      LocateMember method. Placing the responsibility into an Account
      object of doing all of the things an account does (ACcount.Open,
      Acconut.IsValid, Account.Cancel, whatever) PLUS the responsibility
      of understanding that it exists in a repository and manipulating a
      repository is too much responsibility for one object.

      This is my 6 cents... anyone have any other thoughts?

      D

      --- In domaindrivendesign@yahoogroups.com, "Richard Rodseth"
      <rrodseth@...> wrote:
      >
      > I'm trying to be the DDD advocate on my team. A question has arisen
      > about injecting an AccountRepository into the Account entity in
      order
      > to implement Account.findMember.
      >
      > Currently there is a lazily-loaded set of members in the Account
      (we
      > use Hibernate), so findMember could iterate rather than use the
      > repository, but I supect that that design will have to be
      > re-considered to allow for large numbers of members.
      >
      > Personally, I would be comfortable with a business method on a
      service
      > which accessed the repository. But colleagues feel
      Account.findMember
      > () is natural.
      >
      > Any objects to calling a repository from an entity? If so, any good
      > alternatives in this case?
      >
      > Thanks,
      > Richard
      >


    • Randy Stafford
      It s good that you re thinking about allocation of responsibility ; I believe that is at the heart of
      Message 2 of 22 , Sep 29, 2006

        It’s good that you’re thinking about allocation of responsibility; I believe that is at the heart of object-oriented design.  But I agree with Roger that it’s perfectly natural, and pragmatic, for domain objects to depend on repositories.  I’ve written in this forum about that before, as the topic comes up often.

         

        Regarding service layers, as the author of the pattern, first let me state that I began doing DDD in 1988 in Smalltalk without knowing any different, because that’s just how Smalltalkers did things.  Back then it was four-layer architecture in single-tier or fat-client/server systems, with nary a service layer in sight.  As I mused on the four-layer architecture discussion page, I think the advent of distributed object technology and n-tier architecture brought about an evolution in allocation of responsibility which yielded what I conceived as a service layer.  I began using the suffix “Service” in my software architectures in about 1997, in the context of CORBA and RMI –based projects.

         

        But the idea was neither new or mine; it’s timeless.  The Fusion Method people at HP were writing about it (“system interface”, “system operation”) in 1993.  Alistair Cockburn was writing about it (“application boundary”) in 1995.  And what are web services and SOA now but service layers accessed through web protocols and messaging systems?

         

        With service layer it was never my intention to take anything away from DDD, and I regret that some people have interpreted a service layer as an alternative to a domain-driven design.  If you look at my example in PoEAA, and how I articulated the pattern, you’ll see that I intentionally re-used the same example (Revenue Recognition) from the Domain Model pattern, and I intentionally did not move any responsibilities from the domain model to the service layer.  Rather, I added additional responsibilities that I don’t feel are appropriate to allocate to the domain layer.  In my experience as an architect of enterprise applications, I’ve seen certain typical responsibilities – notification of stakeholders (including other systems) that an event has occurred, control of transactions, interaction with external systems, initial access of domain objects, etc. – that I just don’t feel are appropriate to allocate to the domain layer, based on some vague romantic notion of reusability, separation of concerns, etc.

         

        In the end it’s all about allocation of responsibility, and I acknowledge it’s somewhat of an art, with different styles and preferences.  Over the years my idealism has given way to pragmatism to some extent.  But when I build systems I still view service layers and domain layers as complementary, and I don’t mind at all letting domain objects depend on repositories.

         

        Best Regards,

        Randy

         


        From: domaindrivendesign@yahoogroups.com [mailto: domaindrivendesign@yahoogroups.com ] On Behalf Of andrewryan1906
        Sent: Friday, September 29, 2006 9:34 AM
        To: domaindrivendesign@yahoogroups.com
        Subject: [domaindrivendesign] Re: Accounts and Members

         

        Everyone,

        I don't know. I read your replies a bunch of times I see what you're
        saying - but I'd like a little more convincing that injecting a
        repository into a domain object is a good idea.

        Here's my problem - I am fully aware that the repository abstracts
        away the persistence layer, and that no matter what, the domain will
        never know anything about SQL, XML, in-memory, etc... but I still
        have issue with the domain object even knowing to access a
        repository. Back to my currency example - a Currency object should
        know how to convert Money to another type of Money based an exchange
        rate (i.e., USD to Euro at a 1.4% exchange rate)... I think the
        logic to go into a repoistory and look up the currency exchange rate
        is OUTSIDE of the scope of the responsibility for a Currency object.
        Many times when repository access is needed, different objects need
        to be retrieved and other things outside of the scope of the object
        have to happen. It's dangerous to start saddling domain objects with
        the responsibility to access a repository and look things up, I
        think - because they should understand how to interact with each
        other in a world objects simply exist. HOW they come to exist (i.e.,
        from a repository) should be in the Service Layer - I think.

        But I am open to other opinions.

        In particular Roger - I'm curious about your experience with a
        service layer. Can you give a concrete example of how you did
        things, and more specifically, how adding simple functionality
        was "painful?" This would go a long way to seeing if I'm wrong about
        this whole Currency/Account thing.

        D

      • aabelro
        I personally consider that there can be Services in a Domain. They are not mutually exclusive. A Service usually provides, well, naturally, a service to an
        Message 3 of 22 , Sep 29, 2006
          I personally consider that there can be Services in a Domain. They are
          not mutually exclusive. A Service usually provides, well, naturally, a
          service to an object. It does not hold internal state, because it's
          purpose is to provide operations for other domain objects. It
          encapsulates operations which do not belong to a specific object,
          either because the service is useful to more than one object type, or
          because it's something that should be separated from the object, like
          the task of communicating to an external system.

          Abel

          --- In domaindrivendesign@yahoogroups.com, "Randy Stafford"
          <randy.stafford@...> wrote:
          >
          > It's good that you're thinking about allocation of responsibility
          > <http://c2.com/cgi/wiki?AllocationOfResponsibility> ; I believe that is
          > at the heart of object-oriented design. But I agree with Roger that it'
          > s perfectly natural, and pragmatic, for domain objects to depend on
          > repositories. I've written
          > <http://tech.groups.yahoo.com/group/domaindrivendesign/message/2327> in
          > this forum about that before, as the topic comes up often.
          >
          >
          >
          > Regarding service layers, as the author of the pattern, first let me
          > state that I began doing DDD in 1988 in Smalltalk without knowing any
          > different, because that's just how Smalltalkers did things. Back then
          > it was four-layer architecture
          > <http://c2.com/cgi/wiki?FourLayerArchitecture> in single-tier or
          > fat-client/server systems, with nary a service layer in sight. As I
          > mused on the four-layer architecture discussion page
          > <http://c2.com/cgi/wiki?FourLayerArchitectureDiscussion> , I think the
          > advent of distributed object technology and n-tier architecture brought
          > about an evolution in allocation of responsibility which yielded what I
          > conceived as a service layer. I began using the suffix "Service" in my
          > software architectures in about 1997, in the context of CORBA and RMI -
          > based projects.
          >
          >
          >
          > But the idea was neither new or mine; it's timeless. The Fusion Method
          > people at HP were writing
          > <http://www.amazon.com/Object-Oriented-Development-Method-Derek-Coleman/
          > dp/0133388239> about it ("system interface", "system operation") in
          > 1993. Alistair Cockburn was writing
          > <http://www.amazon.com/Pattern-Languages-Program-Design/dp/0201895277>
          > about it ("application boundary") in 1995. And what are web services
          > and SOA now but service layers accessed through web protocols and
          > messaging systems?
          >
          >
          >
          > With service layer it was never my intention to take anything away from
          > DDD, and I regret that some people have interpreted a service layer as
          > an alternative to a domain-driven design. If you look at my example in
          > PoEAA, and how I articulated the pattern, you'll see that I
          > intentionally re-used the same example (Revenue Recognition) from the
          > Domain Model pattern, and I intentionally did not move any
          > responsibilities from the domain model to the service layer. Rather, I
          > added additional responsibilities that I don't feel are appropriate to
          > allocate to the domain layer. In my experience as an architect of
          > enterprise applications, I've seen certain typical responsibilities -
          > notification of stakeholders (including other systems) that an event has
          > occurred, control of transactions, interaction with external systems,
          > initial access of domain objects, etc. - that I just don't feel are
          > appropriate to allocate to the domain layer, based on some vague
          > romantic notion of reusability, separation of concerns, etc.
          >
          >
          >
          > In the end it's all about allocation of responsibility, and I
          > acknowledge it's somewhat of an art, with different styles and
          > preferences. Over the years my idealism has given way to pragmatism to
          > some extent. But when I build systems I still view service layers and
          > domain layers as complementary, and I don't mind at all letting domain
          > objects depend on repositories.
          >
          >
          >
          > Best Regards,
          >
          > Randy
          >
          >
          >
          > ________________________________
          >
          > From: domaindrivendesign@yahoogroups.com
          > [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of andrewryan1906
          > Sent: Friday, September 29, 2006 9:34 AM
          > To: domaindrivendesign@yahoogroups.com
          > Subject: [domaindrivendesign] Re: Accounts and Members
          >
          >
          >
          > Everyone,
          >
          > I don't know. I read your replies a bunch of times I see what you're
          > saying - but I'd like a little more convincing that injecting a
          > repository into a domain object is a good idea.
          >
          > Here's my problem - I am fully aware that the repository abstracts
          > away the persistence layer, and that no matter what, the domain will
          > never know anything about SQL, XML, in-memory, etc... but I still
          > have issue with the domain object even knowing to access a
          > repository. Back to my currency example - a Currency object should
          > know how to convert Money to another type of Money based an exchange
          > rate (i.e., USD to Euro at a 1.4% exchange rate)... I think the
          > logic to go into a repoistory and look up the currency exchange rate
          > is OUTSIDE of the scope of the responsibility for a Currency object.
          > Many times when repository access is needed, different objects need
          > to be retrieved and other things outside of the scope of the object
          > have to happen. It's dangerous to start saddling domain objects with
          > the responsibility to access a repository and look things up, I
          > think - because they should understand how to interact with each
          > other in a world objects simply exist. HOW they come to exist (i.e.,
          > from a repository) should be in the Service Layer - I think.
          >
          > But I am open to other opinions.
          >
          > In particular Roger - I'm curious about your experience with a
          > service layer. Can you give a concrete example of how you did
          > things, and more specifically, how adding simple functionality
          > was "painful?" This would go a long way to seeing if I'm wrong about
          > this whole Currency/Account thing.
          >
          > D
          >
        • Randy Stafford
          Sure, I agree with that, and Eric says as much on p.105 - Services are a common pattern in technical frameworks, but they can also apply in the domain layer .
          Message 4 of 22 , Sep 29, 2006

            Sure, I agree with that, and Eric says as much on p.105 – “Services are a common pattern in technical frameworks, but they can also apply in the domain layer”.

             

            However that’s not what I intended with Service Layer – “Defines an application’s boundary with a layer of services that establishes a set of available operations and coordinates the application’s response in each operation”.  A Service Layer, as I documented it, is comprised of what Eric eloquently describes as “application services” on pp.106-107.

             

            Nor, I dare say, are “domain services” what the Fusion Method people intended with system interface in 1993 – “The interface of a system is the set of system operations to which it can receive [sic] and the set of events that it can output”.  Nor what Alistair Cockburn intended with Application Boundary in 1995: “Define the user interface to be outside the application proper.  Make all functions of the application accessible through a program-driven interface. … [D]etermine the services of the application.  Create a program-driven (not human-driven) interface, on the assumption that one day the application will be driven by a computer system.  The UI is one of several drivers.  All functions of the application must be accessible to the driving system.”

             

            This is one of those cases where a term (service) has multiple distinct meanings, and we need to be clear about which meaning we intend when we use the term in conversation.  Domain services are distinct from Service Layers comprised of application services.  Both ideas are useful and have their place, but should not be confused with each other.

             

            Best Regards,

            Randy

             


            From: domaindrivendesign@yahoogroups.com [mailto: domaindrivendesign@yahoogroups.com ] On Behalf Of aabelro
            Sent: Friday, September 29, 2006 11:46 AM
            To: domaindrivendesign@yahoogroups.com
            Subject: [domaindrivendesign] Re: Accounts and Members

             

            I personally consider that there can be Services in a Domain. They are
            not mutually exclusive. A Service usually provides, well, naturally, a
            service to an object. It does not hold internal state, because it's
            purpose is to provide operations for other domain objects. It
            encapsulates operations which do not belong to a specific object,
            either because the service is useful to more than one object type, or
            because it's something that should be separated from the object, like
            the task of communicating to an external system.

            Abel

            --- In domaindrivendesign@ yahoogroups. com, " Randy Stafford "
            <randy.stafford@ ...> wrote:

            >
            > It's good that you're thinking about allocation of responsibility
            > <http://c2.com/ cgi/wiki? AllocationOfResp onsibility>
            ; I believe that is
            > at the heart of object-oriented design. But I agree with Roger that it'
            > s perfectly natural, and pragmatic, for domain objects to depend on
            > repositories. I've written
            > <
            href="http://tech.groups.yahoo.com/group/domaindrivendesign/message/2327">http://tech. groups.yahoo. com/group/ domaindrivendesi gn/message/ 2327> in
            > this forum about that before, as the topic comes up often.
            >
            >
            >
            > Regarding service layers, as the author of the pattern, first let me
            > state that I began doing DDD in 1988 in Smalltalk without knowing any
            > different, because that's just how Smalltalkers did things. Back then
            > it was four-layer architecture
            > <http://c2.com/ cgi/wiki? FourLayerArchite cture>
            in single-tier or
            > fat-client/server systems, with nary a service layer in sight. As I
            > mused on the four-layer architecture discussion page
            > <http://c2.com/ cgi/wiki? FourLayerArchite ctureDiscussion>
            , I think the
            > advent of distributed object technology and n-tier architecture brought
            > about an evolution in allocation of responsibility which yielded what I
            > conceived as a service layer. I began using the suffix "Service"
            in my
            > software architectures in about 1997, in the context of CORBA and RMI -
            > based projects.
            >
            >
            >
            > But the idea was neither new or mine; it's timeless. The Fusion Method
            > people at HP were writing
            > <
            href="http://www.amazon.com/Object-Oriented-Development-Method-Derek-Coleman/">http://www.amazon. com/Object- Oriented- Development- Method-Derek- Coleman/
            > dp/0133388239> about it ("system interface", "system
            operation") in
            > 1993. Alistair Cockburn was writing
            > <
            href="http://www.amazon.com/Pattern-Languages-Program-Design/dp/0201895277">http://www.amazon. com/Pattern- Languages- Program-Design/ dp/0201895277>
            > about it ("application boundary") in 1995. And what are web
            services
            > and SOA now but service layers accessed through web protocols and
            > messaging systems?
            >
            >
            >
            > With service layer it was never my intention to take anything away from
            > DDD, and I regret that some people have interpreted a service layer as
            > an alternative to a domain-driven design. If you look at my example in
            > PoEAA, and how I articulated the pattern, you'll see that I
            > intentionally re-used the same example (Revenue Recognition) from the
            > Domain Model pattern, and I intentionally did not move any
            > responsibilities from the domain model to the service layer. Rather, I
            > added additional responsibilities that I don't feel are appropriate to
            > allocate to the domain layer. In my experience as an architect of
            > enterprise applications, I've seen certain typical responsibilities -
            > notification of stakeholders (including other systems) that an event has
            > occurred, control of transactions, interaction with external systems,
            > initial access of domain objects, etc. - that I just don't feel are
            > appropriate to allocate to the domain layer, based on some vague
            > romantic notion of reusability, separation of concerns, etc.
            >
            >
            >
            > In the end it's all about allocation of responsibility, and I
            > acknowledge it's somewhat of an art, with different styles and
            > preferences. Over the years my idealism has given way to pragmatism to
            > some extent. But when I build systems I still view service layers and
            > domain layers as complementary, and I don't mind at all letting domain
            > objects depend on repositories.
            >
            >
            >
            > Best Regards,
            >
            > Randy
            >
            >
            >
            > ____________ _________ _________ __
            >
            > From: domaindrivendesign@ yahoogroups. com
            > [mailto:domaindrivendesign@ yahoogroups. com]
            On Behalf Of andrewryan1906
            > Sent: Friday, September 29, 2006 9:34 AM
            > To: domaindrivendesign@ yahoogroups. com
            > Subject: [domaindrivendesign ] Re: Accounts and Members
            >
            >
            >
            > Everyone,
            >
            > I don't know. I read your replies a bunch of times I see what you're
            > saying - but I'd like a little more convincing that injecting a
            > repository into a domain object is a good idea.
            >
            > Here's my problem - I am fully aware that the repository abstracts
            > away the persistence layer, and that no matter what, the domain will
            > never know anything about SQL, XML, in-memory, etc... but I still
            > have issue with the domain object even knowing to access a
            > repository. Back to my currency example - a Currency object should
            > know how to convert Money to another type of Money based an exchange
            > rate (i.e., USD to Euro at a 1.4% exchange rate)... I think the
            > logic to go into a repoistory and look up the currency exchange rate
            > is OUTSIDE of the scope of the responsibility for a Currency object.
            > Many times when repository access is needed, different objects need
            > to be retrieved and other things outside of the scope of the object
            > have to happen. It's dangerous to start saddling domain objects with
            > the responsibility to access a repository and look things up, I
            > think - because they should understand how to interact with each
            > other in a world objects simply exist. HOW they come to exist (i.e.,
            > from a repository) should be in the Service Layer - I think.
            >
            > But I am open to other opinions.
            >
            > In particular Roger - I'm curious about your experience with a
            > service layer. Can you give a concrete example of how you did
            > things, and more specifically, how adding simple functionality
            > was "painful?" This would go a long way to seeing if I'm wrong
            about
            > this whole Currency/Account thing.
            >
            > D
            >

          • aabelro
            I fully agree with you. Abel
            Message 5 of 22 , Sep 29, 2006
              I fully agree with you.

              Abel

              --- In domaindrivendesign@yahoogroups.com, "Randy Stafford"
              <randy.stafford@...> wrote:
              >
              > Sure, I agree with that, and Eric says as much on p.105 - "Services are
              > a common pattern in technical frameworks, but they can also apply in the
              > domain layer".
              >
              >
              >
              > However that's not what I intended with Service Layer - "Defines an
              > application's boundary with a layer of services that establishes a set
              > of available operations and coordinates the application's response in
              > each operation". A Service Layer, as I documented it, is comprised of
              > what Eric eloquently describes as "application services" on pp.106-107.
              >
              >
              >
              > Nor, I dare say, are "domain services" what the Fusion Method people
              > intended with system interface in 1993 - "The interface of a system is
              > the set of system operations to which it can receive [sic] and the set
              > of events that it can output". Nor what Alistair Cockburn intended with
              > Application Boundary in 1995: "Define the user interface to be outside
              > the application proper. Make all functions of the application
              > accessible through a program-driven interface. . [D]etermine the
              > services of the application. Create a program-driven (not human-driven)
              > interface, on the assumption that one day the application will be driven
              > by a computer system. The UI is one of several drivers. All functions
              > of the application must be accessible to the driving system."
              >
              >
              >
              > This is one of those cases where a term (service) has multiple distinct
              > meanings, and we need to be clear about which meaning we intend when we
              > use the term in conversation. Domain services are distinct from Service
              > Layers comprised of application services. Both ideas are useful and
              > have their place, but should not be confused with each other.
              >
              >
              >
              > Best Regards,
              >
              > Randy
              >
              >
              >
              > ________________________________
              >
              > From: domaindrivendesign@yahoogroups.com
              > [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of aabelro
              > Sent: Friday, September 29, 2006 11:46 AM
              > To: domaindrivendesign@yahoogroups.com
              > Subject: [domaindrivendesign] Re: Accounts and Members
              >
              >
              >
              > I personally consider that there can be Services in a Domain. They are
              > not mutually exclusive. A Service usually provides, well, naturally, a
              > service to an object. It does not hold internal state, because it's
              > purpose is to provide operations for other domain objects. It
              > encapsulates operations which do not belong to a specific object,
              > either because the service is useful to more than one object type, or
              > because it's something that should be separated from the object, like
              > the task of communicating to an external system.
              >
              > Abel
              >
              > --- In domaindrivendesign@yahoogroups.com
              > <mailto:domaindrivendesign%40yahoogroups.com> , "Randy Stafford"
              > <randy.stafford@> wrote:
              > >
              > > It's good that you're thinking about allocation of responsibility
              > > <http://c2.com/cgi/wiki?AllocationOfResponsibility
              > <http://c2.com/cgi/wiki?AllocationOfResponsibility> > ; I believe that
              > is
              > > at the heart of object-oriented design. But I agree with Roger that
              > it'
              > > s perfectly natural, and pragmatic, for domain objects to depend on
              > > repositories. I've written
              > > <http://tech.groups.yahoo.com/group/domaindrivendesign/message/2327
              > <http://tech.groups.yahoo.com/group/domaindrivendesign/message/2327> >
              > in
              > > this forum about that before, as the topic comes up often.
              > >
              > >
              > >
              > > Regarding service layers, as the author of the pattern, first let me
              > > state that I began doing DDD in 1988 in Smalltalk without knowing any
              > > different, because that's just how Smalltalkers did things. Back then
              > > it was four-layer architecture
              > > <http://c2.com/cgi/wiki?FourLayerArchitecture
              > <http://c2.com/cgi/wiki?FourLayerArchitecture> > in single-tier or
              > > fat-client/server systems, with nary a service layer in sight. As I
              > > mused on the four-layer architecture discussion page
              > > <http://c2.com/cgi/wiki?FourLayerArchitectureDiscussion
              > <http://c2.com/cgi/wiki?FourLayerArchitectureDiscussion> > , I think the
              > > advent of distributed object technology and n-tier architecture
              > brought
              > > about an evolution in allocation of responsibility which yielded what
              > I
              > > conceived as a service layer. I began using the suffix "Service" in my
              > > software architectures in about 1997, in the context of CORBA and RMI
              > -
              > > based projects.
              > >
              > >
              > >
              > > But the idea was neither new or mine; it's timeless. The Fusion Method
              > > people at HP were writing
              > >
              > <http://www.amazon.com/Object-Oriented-Development-Method-Derek-Coleman/
              > <http://www.amazon.com/Object-Oriented-Development-Method-Derek-Coleman/
              > >
              > > dp/0133388239> about it ("system interface", "system operation") in
              > > 1993. Alistair Cockburn was writing
              > > <http://www.amazon.com/Pattern-Languages-Program-Design/dp/0201895277
              > <http://www.amazon.com/Pattern-Languages-Program-Design/dp/0201895277> >
              > > about it ("application boundary") in 1995. And what are web services
              > > and SOA now but service layers accessed through web protocols and
              > > messaging systems?
              > >
              > >
              > >
              > > With service layer it was never my intention to take anything away
              > from
              > > DDD, and I regret that some people have interpreted a service layer as
              > > an alternative to a domain-driven design. If you look at my example in
              > > PoEAA, and how I articulated the pattern, you'll see that I
              > > intentionally re-used the same example (Revenue Recognition) from the
              > > Domain Model pattern, and I intentionally did not move any
              > > responsibilities from the domain model to the service layer. Rather, I
              > > added additional responsibilities that I don't feel are appropriate to
              > > allocate to the domain layer. In my experience as an architect of
              > > enterprise applications, I've seen certain typical responsibilities -
              > > notification of stakeholders (including other systems) that an event
              > has
              > > occurred, control of transactions, interaction with external systems,
              > > initial access of domain objects, etc. - that I just don't feel are
              > > appropriate to allocate to the domain layer, based on some vague
              > > romantic notion of reusability, separation of concerns, etc.
              > >
              > >
              > >
              > > In the end it's all about allocation of responsibility, and I
              > > acknowledge it's somewhat of an art, with different styles and
              > > preferences. Over the years my idealism has given way to pragmatism to
              > > some extent. But when I build systems I still view service layers and
              > > domain layers as complementary, and I don't mind at all letting domain
              > > objects depend on repositories.
              > >
              > >
              > >
              > > Best Regards,
              > >
              > > Randy
              > >
              > >
              > >
              > > ________________________________
              > >
              > > From: domaindrivendesign@yahoogroups.com
              > <mailto:domaindrivendesign%40yahoogroups.com>
              > > [mailto:domaindrivendesign@yahoogroups.com
              > <mailto:domaindrivendesign%40yahoogroups.com> ] On Behalf Of
              > andrewryan1906
              > > Sent: Friday, September 29, 2006 9:34 AM
              > > To: domaindrivendesign@yahoogroups.com
              > <mailto:domaindrivendesign%40yahoogroups.com>
              > > Subject: [domaindrivendesign] Re: Accounts and Members
              > >
              > >
              > >
              > > Everyone,
              > >
              > > I don't know. I read your replies a bunch of times I see what you're
              > > saying - but I'd like a little more convincing that injecting a
              > > repository into a domain object is a good idea.
              > >
              > > Here's my problem - I am fully aware that the repository abstracts
              > > away the persistence layer, and that no matter what, the domain will
              > > never know anything about SQL, XML, in-memory, etc... but I still
              > > have issue with the domain object even knowing to access a
              > > repository. Back to my currency example - a Currency object should
              > > know how to convert Money to another type of Money based an exchange
              > > rate (i.e., USD to Euro at a 1.4% exchange rate)... I think the
              > > logic to go into a repoistory and look up the currency exchange rate
              > > is OUTSIDE of the scope of the responsibility for a Currency object.
              > > Many times when repository access is needed, different objects need
              > > to be retrieved and other things outside of the scope of the object
              > > have to happen. It's dangerous to start saddling domain objects with
              > > the responsibility to access a repository and look things up, I
              > > think - because they should understand how to interact with each
              > > other in a world objects simply exist. HOW they come to exist (i.e.,
              > > from a repository) should be in the Service Layer - I think.
              > >
              > > But I am open to other opinions.
              > >
              > > In particular Roger - I'm curious about your experience with a
              > > service layer. Can you give a concrete example of how you did
              > > things, and more specifically, how adding simple functionality
              > > was "painful?" This would go a long way to seeing if I'm wrong about
              > > this whole Currency/Account thing.
              > >
              > > D
              > >
              >
            • Sergio Bossa
              ... Roger, I d be interested in knowing why you say that the ONLY solution is that aggregate A uses the aggregate B repository to retrieve a root object for
              Message 6 of 22 , Sep 30, 2006
                On 9/29/06, Stasko, Roger <Roger.Stasko@...> wrote:

                The thing I like about the repository pattern is spells out the relationship between aggregates.
                 
                If aggregate A (invoice, for example) needs access to aggregate B (order, for example), then the ONLY solution is that aggregate A uses the aggregate B repository to retrieve a root object for aggregate B. 

                Roger, I'd be interested in knowing why you say that "the ONLY solution is that aggregate A uses the aggregate B repository to retrieve a root object for aggregate B". Why can not aggregate A directly hold a reference to aggregate B?

                Thanks,
                Cheers,

                Sergio B.

                --
                Sergio Bossa
                Software developer and analyst, blogger and Open Source enthusiast.
                Blogging on: http://sbtourist.blogspot.com
              • Sergio Bossa
                ... +1 I always use a Service Layer in my projects. Other than providing a place for allocating external responsibilities like you say, I find it invaluable
                Message 7 of 22 , Sep 30, 2006
                  On 9/29/06, Randy Stafford <randy.stafford@...> wrote:

                  In my experience as an architect of enterprise applications, I've seen certain typical responsibilities – notification of stakeholders (including other systems) that an event has occurred, control of transactions, interaction with external systems, initial access of domain objects, etc. – that I just don't feel are appropriate to allocate to the domain layer, based on some vague romantic notion of reusability, separation of concerns, etc.

                  In the end it's all about allocation of responsibility, and I acknowledge it's somewhat of an art, with different styles and preferences.  Over the years my idealism has given way to pragmatism to some extent.  But when I build systems I still view service layers and domain layers as complementary, and I don't mind at all letting domain objects depend on repositories.


                  +1
                  I always use a Service Layer in my projects.
                  Other than providing a place for allocating "external" responsibilities like you say, I  find it invaluable for providing a coarse grained use case driven interface to clients.

                  Cheers,

                  Sergio B.

                  --
                  Sergio Bossa
                  Software developer and analyst, blogger and Open Source enthusiast.
                  Blogging on: http://sbtourist.blogspot.com
                • Udi Dahan
                  Maybe the title of this thread should be updated. So why is the idea that a domain object should even know there exists a repository of other domain objects
                  Message 8 of 22 , Oct 1, 2006

                    Maybe the title of this thread should be updated.

                     

                    So why is the "idea that a domain object should even know there exists a

                    repository of other domain objects" against DDD?

                     

                    I wouldn’t say it’s against DDD, but that it comes from a sense of aesthetics of design.

                     

                    As far as I can tell, this idea doesn't come from Eric's book, nor does

                    it appear in Fowler's PofEAA book.

                     

                    You’re right.

                     

                    The justification for this idea suggests that we need to bend over

                    backwards to enable some small aspect of our application to be

                    independent and interchangeable. Now, if there is a specific business

                    requirement that makes this important that is one thing. But I don't

                    care for the idea of doing this in the pursuit of design purity.

                     

                    I wouldn’t go so far as to say “bend over backwards”, and we’re talking about the core logic of the system here, not “some small aspect”.

                     

                    One of the refreshing things about DDD is the notion of bounded contexts

                    and pragmatic modeling (use modeling to solve application problems not

                    to produce "pure" designs). What we're trying to accomplish is to build

                    a sensibly-designed, coherent working application within a specific

                    bounded context. By properly identifying our aggregates and effectively

                    using repositories to keep those aggregates independent of each other

                    we've gone a long way to creating a robust application.

                     

                    What does you mean to keep “those aggregates independent of each other”? What this means to me is that domain objects from one aggregate would not be involved in the same graph as those from a different aggregate – for instance, if Employee is in one aggregate, and Customer and Order are in another, the following code would not appear:

                     

                    myEmployee.Customers

                    or

                    myEmployee.Orders

                     

                    However, the class Employee could still be aware of the other two classes – contain methods that accept them as parameters.

                     

                    Anyway, this is what’s been working for me.

                    Hope it helps.

                     

                     

                    Udi Dahan - The Software Simplist

                    .Net Development Expert & SOA Specialist

                     

                    email:   Udi@...

                    mobile:  +972-(0)522-888-426

                    web:     http://www.UdiDahan.com

                    connect: LinkedIn

                     

                    Microsoft Solutions Architect MVP

                     

                     

                    Microsoft Israel Certified .Net Expert

                     

                               

                     

                     


                    --
                    No virus found in this outgoing message.
                    Checked by AVG Free Edition.
                    Version: 7.1.405 / Virus Database: 268.12.9/458 - Release Date: 27/9/2006

                  • paul_gielens
                    Consider the following example (borrowed from DDD). It is to my belief that repositories are part of the domain, and thus Domain Objects may depend on
                    Message 9 of 22 , Oct 1, 2006

                      Consider the following example (borrowed from DDD).

                      It is to my belief that repositories are part of the domain, and thus Domain Objects may depend on repositories. Both of the following implementations are valid.

                      public class Car
                      {
                        .. 

                        public void StartEngine()
                        {
                          Engine.Start();
                        }

                        public Engine Engine
                        {
                          return engineRepository.ForCarId(id);
                        }
                      }

                      or

                      public class Car
                      {
                        ..

                        public void StartEngine()
                        {
                          Engine v6 = engineRepository.ForCarId(id);
                          v6.Start();
                        }
                      }

                      Any thoughts?

                      Kind regards,
                      Paul Gielens
                      http://weblogs.asp.net/pgielens

                    • Stasko, Roger
                      A can certainly hold a reference to B; but I was thinking about the original context of this thread -- that A and B were independent aggregates. Or perhaps
                      Message 10 of 22 , Oct 2, 2006
                        A can certainly hold a reference to B; but I was thinking about the original context of this thread -- that A and B were independent aggregates.  Or perhaps that was a bad assumption?


                        From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Sergio Bossa
                        Sent: Saturday, September 30, 2006 3:22 AM
                        To: domaindrivendesign@yahoogroups.com
                        Subject: Re: [domaindrivendesign] Re: Accounts and Members

                        On 9/29/06, Stasko, Roger <Roger.Stasko@ libertymutual. com> wrote:


                        The thing I like about the repository pattern is spells out the relationship between aggregates.
                         
                        If aggregate A (invoice, for example) needs access to aggregate B (order, for example), then the ONLY solution is that aggregate A uses the aggregate B repository to retrieve a root object for aggregate B. 

                        Roger, I'd be interested in knowing why you say that "the ONLY solution is that aggregate A uses the aggregate B repository to retrieve a root object for aggregate B". Why can not aggregate A directly hold a reference to aggregate B?

                        Thanks,
                        Cheers,

                        Sergio B.

                        --
                        Sergio Bossa
                        Software developer and analyst, blogger and Open Source enthusiast.
                        Blogging on: http://sbtourist. blogspot. com

                      • ornot2006
                        Hi,Randy, I am a newbie on DDD. Even I can tell the difference between the Domain Service and Service Layer, I can not help myself to put many business logics
                        Message 11 of 22 , Oct 3, 2006
                          Hi,Randy,
                          I am a newbie on DDD. Even I can tell the difference between the
                          Domain Service and Service Layer, I can not help myself to put many
                          business logics into the domain services and eventually get some
                          things like this:

                          Service Layer
                          -------------------------------------------------------
                          |
                          Domain Service
                          |
                          Entity, Value Object,Factory,Repository




                          Most probably, the service Layer just simply delegates the
                          invocation to the domian service .


                          My confusion mainly come from the question: Whose responsiblity
                          is it to coordinate the domain object in order to fufill some
                          business rules since the Service layer should be kept very thin?

                          I am struggling with this very long and hope getting your helps.

                          Regards
                          OrNot






                          --- In domaindrivendesign@yahoogroups.com, "Randy Stafford"
                          <randy.stafford@...> wrote:
                          >
                          > Sure, I agree with that, and Eric says as much on p.105 -
                          "Services are
                          > a common pattern in technical frameworks, but they can also apply
                          in the
                          > domain layer".
                          >
                          >
                          >
                          > However that's not what I intended with Service Layer - "Defines an
                          > application's boundary with a layer of services that establishes a
                          set
                          > of available operations and coordinates the application's response
                          in
                          > each operation". A Service Layer, as I documented it, is
                          comprised of
                          > what Eric eloquently describes as "application services" on pp.106-
                          107.
                          >
                          >
                          >
                          > Nor, I dare say, are "domain services" what the Fusion Method
                          people
                          > intended with system interface in 1993 - "The interface of a
                          system is
                          > the set of system operations to which it can receive [sic] and the
                          set
                          > of events that it can output". Nor what Alistair Cockburn
                          intended with
                          > Application Boundary in 1995: "Define the user interface to be
                          outside
                          > the application proper. Make all functions of the application
                          > accessible through a program-driven interface. . [D]etermine the
                          > services of the application. Create a program-driven (not human-
                          driven)
                          > interface, on the assumption that one day the application will be
                          driven
                          > by a computer system. The UI is one of several drivers. All
                          functions
                          > of the application must be accessible to the driving system."
                          >
                          >
                          >
                          > This is one of those cases where a term (service) has multiple
                          distinct
                          > meanings, and we need to be clear about which meaning we intend
                          when we
                          > use the term in conversation. Domain services are distinct from
                          Service
                          > Layers comprised of application services. Both ideas are useful
                          and
                          > have their place, but should not be confused with each other.
                          >
                          >
                          >
                          > Best Regards,
                          >
                          > Randy
                          >
                          >
                          >
                          > ________________________________
                          >
                          > From: domaindrivendesign@yahoogroups.com
                          > [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of aabelro
                          > Sent: Friday, September 29, 2006 11:46 AM
                          > To: domaindrivendesign@yahoogroups.com
                          > Subject: [domaindrivendesign] Re: Accounts and Members
                          >
                          >
                          >
                          > I personally consider that there can be Services in a Domain. They
                          are
                          > not mutually exclusive. A Service usually provides, well,
                          naturally, a
                          > service to an object. It does not hold internal state, because it's
                          > purpose is to provide operations for other domain objects. It
                          > encapsulates operations which do not belong to a specific object,
                          > either because the service is useful to more than one object type,
                          or
                          > because it's something that should be separated from the object,
                          like
                          > the task of communicating to an external system.
                          >
                          > Abel
                          >
                          > --- In domaindrivendesign@yahoogroups.com
                          > <mailto:domaindrivendesign%40yahoogroups.com> , "Randy Stafford"
                          > <randy.stafford@> wrote:
                          > >
                          > > It's good that you're thinking about allocation of responsibility
                          > > <http://c2.com/cgi/wiki?AllocationOfResponsibility
                          > <http://c2.com/cgi/wiki?AllocationOfResponsibility> > ; I believe
                          that
                          > is
                          > > at the heart of object-oriented design. But I agree with Roger
                          that
                          > it'
                          > > s perfectly natural, and pragmatic, for domain objects to depend
                          on
                          > > repositories. I've written
                          > >
                          <http://tech.groups.yahoo.com/group/domaindrivendesign/message/2327
                          >
                          <http://tech.groups.yahoo.com/group/domaindrivendesign/message/2327>
                          >
                          > in
                          > > this forum about that before, as the topic comes up often.
                          > >
                          > >
                          > >
                          > > Regarding service layers, as the author of the pattern, first
                          let me
                          > > state that I began doing DDD in 1988 in Smalltalk without
                          knowing any
                          > > different, because that's just how Smalltalkers did things. Back
                          then
                          > > it was four-layer architecture
                          > > <http://c2.com/cgi/wiki?FourLayerArchitecture
                          > <http://c2.com/cgi/wiki?FourLayerArchitecture> > in single-tier or
                          > > fat-client/server systems, with nary a service layer in sight.
                          As I
                          > > mused on the four-layer architecture discussion page
                          > > <http://c2.com/cgi/wiki?FourLayerArchitectureDiscussion
                          > <http://c2.com/cgi/wiki?FourLayerArchitectureDiscussion> > , I
                          think the
                          > > advent of distributed object technology and n-tier architecture
                          > brought
                          > > about an evolution in allocation of responsibility which yielded
                          what
                          > I
                          > > conceived as a service layer. I began using the suffix "Service"
                          in my
                          > > software architectures in about 1997, in the context of CORBA
                          and RMI
                          > -
                          > > based projects.
                          > >
                          > >
                          > >
                          > > But the idea was neither new or mine; it's timeless. The Fusion
                          Method
                          > > people at HP were writing
                          > >
                          > <http://www.amazon.com/Object-Oriented-Development-Method-Derek-
                          Coleman/
                          > <http://www.amazon.com/Object-Oriented-Development-Method-Derek-
                          Coleman/
                          > >
                          > > dp/0133388239> about it ("system interface", "system operation")
                          in
                          > > 1993. Alistair Cockburn was writing
                          > > <http://www.amazon.com/Pattern-Languages-Program-
                          Design/dp/0201895277
                          > <http://www.amazon.com/Pattern-Languages-Program-
                          Design/dp/0201895277> >
                          > > about it ("application boundary") in 1995. And what are web
                          services
                          > > and SOA now but service layers accessed through web protocols and
                          > > messaging systems?
                          > >
                          > >
                          > >
                          > > With service layer it was never my intention to take anything
                          away
                          > from
                          > > DDD, and I regret that some people have interpreted a service
                          layer as
                          > > an alternative to a domain-driven design. If you look at my
                          example in
                          > > PoEAA, and how I articulated the pattern, you'll see that I
                          > > intentionally re-used the same example (Revenue Recognition)
                          from the
                          > > Domain Model pattern, and I intentionally did not move any
                          > > responsibilities from the domain model to the service layer.
                          Rather, I
                          > > added additional responsibilities that I don't feel are
                          appropriate to
                          > > allocate to the domain layer. In my experience as an architect of
                          > > enterprise applications, I've seen certain typical
                          responsibilities -
                          > > notification of stakeholders (including other systems) that an
                          event
                          > has
                          > > occurred, control of transactions, interaction with external
                          systems,
                          > > initial access of domain objects, etc. - that I just don't feel
                          are
                          > > appropriate to allocate to the domain layer, based on some vague
                          > > romantic notion of reusability, separation of concerns, etc.
                          > >
                          > >
                          > >
                          > > In the end it's all about allocation of responsibility, and I
                          > > acknowledge it's somewhat of an art, with different styles and
                          > > preferences. Over the years my idealism has given way to
                          pragmatism to
                          > > some extent. But when I build systems I still view service
                          layers and
                          > > domain layers as complementary, and I don't mind at all letting
                          domain
                          > > objects depend on repositories.
                          > >
                          > >
                          > >
                          > > Best Regards,
                          > >
                          > > Randy
                          > >
                          > >
                          > >
                          > > ________________________________
                          > >
                          > > From: domaindrivendesign@yahoogroups.com
                          > <mailto:domaindrivendesign%40yahoogroups.com>
                          > > [mailto:domaindrivendesign@yahoogroups.com
                          > <mailto:domaindrivendesign%40yahoogroups.com> ] On Behalf Of
                          > andrewryan1906
                          > > Sent: Friday, September 29, 2006 9:34 AM
                          > > To: domaindrivendesign@yahoogroups.com
                          > <mailto:domaindrivendesign%40yahoogroups.com>
                          > > Subject: [domaindrivendesign] Re: Accounts and Members
                          > >
                          > >
                          > >
                          > > Everyone,
                          > >
                          > > I don't know. I read your replies a bunch of times I see what
                          you're
                          > > saying - but I'd like a little more convincing that injecting a
                          > > repository into a domain object is a good idea.
                          > >
                          > > Here's my problem - I am fully aware that the repository
                          abstracts
                          > > away the persistence layer, and that no matter what, the domain
                          will
                          > > never know anything about SQL, XML, in-memory, etc... but I
                          still
                          > > have issue with the domain object even knowing to access a
                          > > repository. Back to my currency example - a Currency object
                          should
                          > > know how to convert Money to another type of Money based an
                          exchange
                          > > rate (i.e., USD to Euro at a 1.4% exchange rate)... I think the
                          > > logic to go into a repoistory and look up the currency exchange
                          rate
                          > > is OUTSIDE of the scope of the responsibility for a Currency
                          object.
                          > > Many times when repository access is needed, different objects
                          need
                          > > to be retrieved and other things outside of the scope of the
                          object
                          > > have to happen. It's dangerous to start saddling domain objects
                          with
                          > > the responsibility to access a repository and look things up, I
                          > > think - because they should understand how to interact with each
                          > > other in a world objects simply exist. HOW they come to exist
                          (i.e.,
                          > > from a repository) should be in the Service Layer - I think.
                          > >
                          > > But I am open to other opinions.
                          > >
                          > > In particular Roger - I'm curious about your experience with a
                          > > service layer. Can you give a concrete example of how you did
                          > > things, and more specifically, how adding simple functionality
                          > > was "painful?" This would go a long way to seeing if I'm wrong
                          about
                          > > this whole Currency/Account thing.
                          > >
                          > > D
                          > >
                          >
                        • Randy Stafford
                          There are no hard-and-fast rules; no one-size-fits-all prescription. Business rules is such a vague term. And there is context-dependency. In general, an
                          Message 12 of 22 , Oct 4, 2006

                            There are no hard-and-fast rules; no one-size-fits-all prescription.  “Business rules” is such a vague term.  And there is context-dependency.  In general, an application is responsible for protecting the interests of certain stakeholders, not least of which might be some business funding the development and operation of the application, whose “rules” are encoded in logic in the application.  That logic may be in method code of traditional domain object classes.  Or you might even implement classes modeling rules (I’ve done that), and let traditional domain object instances refer to instances of those classes.  You might have Strategy patterns, or Specifications.  You might even put some logic (e.g. duplicate identifier detection) “above” (or “below”) the layer of traditional domain object classes.  The easiest way to articulate rationale for responsibility allocation decisions is to talk about one real-life example at a time, instead of starting with generalities and claiming they apply.  But I’m not going to ask you to describe your real-life example, because that will take you some time to do, and I may not have time to answer.

                             

                            Best Regards,

                            Randy

                             


                            From: domaindrivendesign@yahoogroups.com [mailto: domaindrivendesign@yahoogroups.com ] On Behalf Of ornot2006
                            Sent: Tuesday, October 03, 2006 8:42 PM
                            To: domaindrivendesign@yahoogroups.com
                            Subject: [domaindrivendesign] Re: Accounts and Members

                             

                            Hi,Randy,
                            I am a newbie on DDD. Even I can tell the difference between the
                            Domain Service and Service Layer, I can not help myself to put many
                            business logics into the domain services and eventually get some
                            things like this:

                            Service Layer
                            ------------ --------- --------- --------- --------- -------
                            |
                            Domain Service
                            |
                            Entity, Value Object,Factory, Repository

                            Most probably, the service Layer just simply delegates the
                            invocation to the domian service .

                            My confusion mainly come from the question: Whose responsiblity
                            is it to coordinate the domain object in order to fufill some
                            business rules since the Service layer should be kept very thin?

                            I am struggling with this very long and hope getting your helps.

                            Regards
                            OrNot



                            --- In domaindrivendesign@ yahoogroups. com, " Randy Stafford "
                            <randy.stafford@ ...> wrote:

                            >
                            > Sure, I agree with that, and Eric says as much on p.105 -
                            "Services are
                            > a common pattern in technical frameworks, but they can also apply
                            in the
                            > domain layer".
                            >
                            >
                            >
                            > However that's not what I intended with Service Layer - "Defines an
                            > application' s boundary with a layer of services that establishes a
                            set
                            > of available operations and coordinates the application' s response
                            in
                            > each operation". A Service Layer, as I documented it, is
                            comprised of
                            > what Eric eloquently describes as "application services" on
                            pp.106-
                            107.
                            >
                            >
                            >
                            > Nor, I dare say, are "domain services" what the Fusion Method
                            people
                            > intended with system interface in 1993 - "The interface of a
                            system is
                            > the set of system operations to which it can receive [sic] and the
                            set
                            > of events that it can output". Nor what Alistair Cockburn
                            intended with
                            > Application Boundary in 1995: "Define the user interface to be
                            outside
                            > the application proper. Make all functions of the application
                            > accessible through a program-driven interface. . [D]etermine the
                            > services of the application. Create a program-driven (not human-
                            driven)
                            > interface, on the assumption that one day the application will be
                            driven
                            > by a computer system. The UI is one of several drivers. All
                            functions
                            > of the application must be accessible to the driving system."
                            >
                            >
                            >
                            > This is one of those cases where a term (service) has multiple
                            distinct
                            > meanings, and we need to be clear about which meaning we intend
                            when we
                            > use the term in conversation. Domain services are distinct from
                            Service
                            > Layers comprised of application services. Both ideas are useful
                            and
                            > have their place, but should not be confused with each other.
                            >
                            >
                            >
                            > Best Regards,
                            >
                            > Randy
                            >
                            >
                            >
                            > ____________ _________ _________ __
                            >
                            > From: domaindrivendesign@ yahoogroups. com
                            > [mailto:domaindrivendesign@ yahoogroups. com]
                            On Behalf Of aabelro
                            > Sent: Friday, September 29, 2006 11:46 AM
                            > To: domaindrivendesign@ yahoogroups. com
                            > Subject: [domaindrivendesign ] Re: Accounts and Members
                            >
                            >
                            >
                            > I personally consider that there can be Services in a Domain. They
                            are
                            > not mutually exclusive. A Service usually provides, well,
                            naturally, a
                            > service to an object. It does not hold internal state, because it's
                            > purpose is to provide operations for other domain objects. It
                            > encapsulates operations which do not belong to a specific object,
                            > either because the service is useful to more than one object type,
                            or
                            > because it's something that should be separated from the object,
                            like
                            > the task of communicating to an external system.
                            >
                            > Abel
                            >
                            > --- In domaindrivendesign@ yahoogroups. com
                            > <mailto:domaindrive ndesign%40yahoog roups.com> , "
                            w:st="on">Randy Stafford "
                            > <randy.stafford@ > wrote:
                            > >
                            > > It's good that you're thinking about allocation of responsibility
                            > > <http://c2.com/ cgi/wiki? AllocationOfResp onsibility
                            > <http://c2.com/ cgi/wiki? AllocationOfResp onsibility> > ; I believe
                            that
                            > is
                            > > at the heart of object-oriented design. But I agree with Roger
                            that
                            > it'
                            > > s perfectly natural, and pragmatic, for domain objects to depend
                            on
                            > > repositories. I've written
                            > >
                            <http://tech. groups.yahoo. com/group/ domaindrivendesi gn/message/ 2327
                            >
                            <http://tech. groups.yahoo. com/group/ domaindrivendesi gn/message/ 2327>
                            >
                            > in
                            > > this forum about that before, as the topic comes up often.
                            > >
                            > >
                            > >
                            > > Regarding service layers, as the author of the pattern, first
                            let me
                            > > state that I began doing DDD in 1988 in Smalltalk without
                            knowing any
                            > > different, because that's just how Smalltalkers did things. Back
                            then
                            > > it was four-layer architecture
                            > > <http://c2.com/ cgi/wiki? FourLayerArchite cture
                            > <http://c2.com/ cgi/wiki? FourLayerArchite cture> > in single-tier or
                            > > fat-client/server systems, with nary a service layer in sight.
                            As I
                            > > mused on the four-layer architecture discussion page
                            > > <http://c2.com/ cgi/wiki? FourLayerArchite ctureDiscussion
                            > <http://c2.com/ cgi/wiki? FourLayerArchite ctureDiscussion> > , I
                            think the
                            > > advent of distributed object technology and n-tier architecture
                            > brought
                            > > about an evolution in allocation of responsibility which yielded
                            what
                            > I
                            > > conceived as a service layer. I began using the suffix
                            "Service"
                            in my
                            > > software architectures in about 1997, in the context of CORBA
                            and RMI
                            > -
                            > > based projects.
                            > >
                            > >
                            > >
                            > > But the idea was neither new or mine; it's timeless. The Fusion
                            Method
                            > > people at HP were writing
                            > >
                            > <
                            href="http://www.amazon.com/Object-Oriented-Development-Method-Derek-">http://www.amazon. com/Object- Oriented- Development- Method-Derek-
                            Coleman/
                            > <
                            href="http://www.amazon.com/Object-Oriented-Development-Method-Derek-">http://www.amazon. com/Object- Oriented- Development- Method-Derek-
                            Coleman/
                            > >
                            > > dp/0133388239> about it ("system interface",
                            "system operation")
                            in
                            > > 1993. Alistair Cockburn was writing
                            > > <http://www.amazon. com/Pattern- Languages- Program-
                            Design/dp/020189527 7
                            > <http://www.amazon. com/Pattern- Languages- Program-
                            Design/dp/020189527 7> >
                            > > about it ("application boundary") in 1995. And what are web
                            services
                            > > and SOA now but service layers accessed through web protocols and
                            > > messaging systems?
                            > >
                            > >
                            > >
                            > > With service layer it was never my intention to take anything
                            away
                            > from
                            > > DDD, and I regret that some people have interpreted a service
                            layer as
                            > > an alternative to a domain-driven design. If you look at my
                            example in
                            > > PoEAA, and how I articulated the pattern, you'll see that I
                            > > intentionally re-used the same example (Revenue Recognition)
                            from the
                            > > Domain Model pattern, and I intentionally did not move any
                            > > responsibilities from the domain model to the service layer.
                            Rather, I
                            > > added additional responsibilities that I don't feel are
                            appropriate to
                            > > allocate to the domain layer. In my experience as an architect of
                            > > enterprise applications, I've seen certain typical
                            responsibilities -
                            > > notification of stakeholders (including other systems) that an
                            event
                            > has
                            > > occurred, control of transactions, interaction with external
                            systems,
                            > > initial access of domain objects, etc. - that I just don't feel
                            are
                            > > appropriate to allocate to the domain layer, based on some vague
                            > > romantic notion of reusability, separation of concerns, etc.
                            > >
                            > >
                            > >
                            > > In the end it's all about allocation of responsibility, and I
                            > > acknowledge it's somewhat of an art, with different styles and
                            > > preferences. Over the years my idealism has given way to
                            pragmatism to
                            > > some extent. But when I build systems I still view service
                            layers and
                            > > domain layers as complementary, and I don't mind at all letting
                            domain
                            > > objects depend on repositories.
                            > >
                            > >
                            > >
                            > > Best Regards,
                            > >
                            > > Randy
                            > >
                            > >
                            > >
                            > > ____________ _________ _________ __
                            > >
                            > > From: domaindrivendesign@ yahoogroups. com
                            > <mailto:domaindrive ndesign%40yahoog roups.com>
                            > > [mailto:domaindrivendesign@ yahoogroups. com
                            > <mailto:domaindrive ndesign%40yahoog roups.com> ] On Behalf
                            Of
                            > andrewryan1906
                            > > Sent: Friday, September 29, 2006 9:34 AM
                            > > To: domaindrivendesign@ yahoogroups. com
                            > <mailto:domaindrive ndesign%40yahoog roups.com>
                            > > Subject: [domaindrivendesign ] Re: Accounts and Members
                            > >
                            > >
                            > >
                            > > Everyone,
                            > >
                            > > I don't know. I read your replies a bunch of times I see what
                            you're
                            > > saying - but I'd like a little more convincing that injecting a
                            > > repository into a domain object is a good idea.
                            > >
                            > > Here's my problem - I am fully aware that the repository
                            abstracts
                            > > away the persistence layer, and that no matter what, the domain
                            will
                            > > never know anything about SQL, XML, in-memory, etc... but I
                            still
                            > > have issue with the domain object even knowing to access a
                            > > repository. Back to my currency example - a Currency object
                            should
                            > > know how to convert Money to another type of Money based an
                            exchange
                            > > rate (i.e., USD to Euro at a 1.4% exchange rate)... I think the
                            > > logic to go into a repoistory and look up the currency exchange
                            rate
                            > > is OUTSIDE of the scope of the responsibility for a Currency
                            object.
                            > > Many times when repository access is needed, different objects
                            need
                            > > to be retrieved and other things outside of the scope of the
                            object
                            > > have to happen. It's dangerous to start saddling domain objects
                            with
                            > > the responsibility to access a repository and look things up, I
                            > > think - because they should understand how to interact with each
                            > > other in a world objects simply exist. HOW they come to exist
                            (i.e.,
                            > > from a repository) should be in the Service Layer - I think.
                            > >
                            > > But I am open to other opinions.
                            > >
                            > > In particular Roger - I'm curious about your experience with a
                            > > service layer. Can you give a concrete example of how you did
                            > > things, and more specifically, how adding simple functionality
                            > > was "painful?" This would go a long way to seeing if I'm
                            wrong
                            about
                            > > this whole Currency/Account thing.
                            > >
                            > > D
                            > >
                            >

                          • colin.jack
                            This is the sort of approach we use too. I personally prefer to completely avoid accessing repositories from the domain classes, as far as possible. ...
                            Message 13 of 22 , May 3, 2007
                              This is the sort of approach we use too. I personally prefer to
                              completely avoid accessing repositories from the domain classes, as
                              far as possible.

                              --- In domaindrivendesign@yahoogroups.com, "andrewryan1906"
                              <andrew1906@...> wrote:
                              >
                              > And... another thing to clarify. I misspoke earlier - clearly,
                              > Repositories are part of the domain. What I meant to say is, they
                              > should not be part of the CORE domain. So if I'm building
                              recruiting
                              > object, the Candidate object should be able to:
                              >
                              > Candidate.Hire();
                              > Candidate.Fire();
                              > Candidate.RateLevelofInterest();
                              >
                              > but the candidate should NOT be able to:
                              >
                              > Candidate.MatchToJobs();
                              >
                              > I'm saying this because this requires access to the JobRepository,
                              > which IMO is outside of the core domain and a part of the
                              supporting
                              > domain. Thus, the method should read:
                              >
                              > Candidate.IsAMatchWithJob( Job jobTobeMatched )
                              >
                              > and there should be another, thin method OUTSIDE of the Core Domain
                              > that says:
                              >
                              > public void CandidateService.MatchToJobs( Candidate c )
                              > {
                              > IList jobs = new List();
                              > foreach( Job j in JobRepository.Singleton.GetAll() )
                              > if ( c.IsMatchWithJob( j ) )
                              > jobs.Add( j );
                              >
                              > return j;
                              > }
                              >
                              > That's what I mean by leaving all of the work in the core domain,
                              > EXCEPT the process of getting things from the repository.
                              >
                              > Thanks,
                              > Andrew
                              >
                            Your message has been successfully submitted and would be delivered to recipients shortly.