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

DTO objects in the domain

Expand Messages
  • stuart_faircloth
    Hi, My architecture is very simple. We have an entry point (service) into the system which receives a DTO: interface XXXService { void
    Message 1 of 21 , Dec 24, 2009
    View Source
    • 0 Attachment
      Hi,

      My architecture is very simple. We have an entry point (service) into the system which receives a DTO:

      interface XXXService {
      void provideXXXFunctionality(XXXDTO dto);
      }

      These DTOs are then used to update domain objects. The DTO is complex and can update many objects under an aggregate root. How is the updating of the domain object best achieved?

      1. I could add a method to the domain object and for each child object from the root pass the DTO and have the object update itself:

      class Domain {
      public void updateForXXX(XXXDTO dto);
      }

      But ideally I would like to keep the DTO out of the domain.

      2. I could create a command to wrap the DTO but IMHO this removes the business logic from the domain to the command and the functionality could be implemented in the XXXService.provideXXXFunctionality method

      3. Visitor pattern? Same drawbacks as the command pattern
    • vvernon_shiftmethod
      Stuart, I have a few thoughts on this. ... The only things that belong in your domain are terms from you UL. Also DTOs are not domain objects. They are anemic
      Message 2 of 21 , Dec 26, 2009
      View Source
      • 0 Attachment
        Stuart,

        I have a few thoughts on this.

        > 1. I could add a method to the domain object and for each
        > child object from the root pass the DTO and have the object
        > update itself:

        The only things that belong in your domain are terms from you UL. Also DTOs are not domain objects. They are anemic objects that help bridge physical tiers in separate processes. You could consider making your application layer service methods receive serialized domain command objects instead. But if you are tied to DTOs in the application layer, at a minimum you need to translate DTOs into domain objects (see below).

        > 2. I could create a command to wrap the DTO but IMHO this
        > removes the business logic from the domain to the command
        > and the functionality could be implemented in the
        > XXXService.provideXXXFunctionality method

        If you create commands, don't make them DTO wrappers. Also, commands don't have to implement the mutation behavior on the aggregates. More often, IMO, a command tells the aggregate what to do and with what, but doesn't do the command.

        > 3. Visitor pattern? Same drawbacks as the command pattern

        Well, I think the behavior is better if implemented in the aggregate. But it might depend on the level of complexity.

        All the above considered, I wonder if your application service methods are revealing domain responsibilities. Remember that Domain Services are meant to deal with domain behavior that doesn't fit or belong on any one domain object (aggregate, entity, value, whatever). Rather the Domain Service orchestrates behaviors across multiple domain objects. So as your application service requests arrive, consider translating the DTOs into domain objects of some kind, either commands or value objects. Then invoke a Domain Service method, which as a receiver might be named closely to the application service sender, passing the translated parameters (command or value objects). That Domain Service would use Repositories to find aggregates that overlap in the use case / user story, and invoke command methods on those aggregates, passing the applicable parts of the parameter domain objects (commands or value objects). That will help correctly keep your application services thin and retain your business logic only in the core domain model.

        Vaughn



        --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@...> wrote:
        >
        > Hi,
        >
        > My architecture is very simple. We have an entry point (service) into the system which receives a DTO:
        >
        > interface XXXService {
        > void provideXXXFunctionality(XXXDTO dto);
        > }
        >
        > These DTOs are then used to update domain objects. The DTO is complex and can update many objects under an aggregate root. How is the updating of the domain object best achieved?
        >
        > 1. I could add a method to the domain object and for each child object from the root pass the DTO and have the object update itself:
        >
        > class Domain {
        > public void updateForXXX(XXXDTO dto);
        > }
        >
        > But ideally I would like to keep the DTO out of the domain.
        >
        > 2. I could create a command to wrap the DTO but IMHO this removes the business logic from the domain to the command and the functionality could be implemented in the XXXService.provideXXXFunctionality method
        >
        > 3. Visitor pattern? Same drawbacks as the command pattern
        >
      • stuart_faircloth
        Here is a different example // domain object(s) class Order { // large number of properties } class OrderLine { Order createOrder(CreateOrderDTO dto); } // dto
        Message 3 of 21 , Jan 13, 2010
        View Source
        • 0 Attachment
          Here is a different example

          // domain object(s)
          class Order {
          // large number of properties
          }

          class OrderLine {
          Order createOrder(CreateOrderDTO dto);
          }

          // dto (complex object)
          class CreateOrderRequestDTO {
          String orderType;
          double qty;
          .....
          }

          How would you remove the DTO? I could replace it with another object (specification?) but that would have almost the same properties as the DTO.

          Here is another example:

          // dto
          class ModifyOrderRequestDTO {
          X x;
          Y y;
          }

          // domain object
          class Order {
          public void modify(ModifyOrderRequestDTO modification) {
          setX(modification.x);
          setY(modification.y);
          }
          }

          possible soln (doesn't appear to provide any benefits):

          class Transformer {
          ModifyRequest transform(ModifyRequestDTO dto) {
          return new ModifyRequest(dto.x, dto.y);
          }
          }


          class ModifyRequest {
          X x;
          Y y;

          void applyTo(Order order) {
          order.setX(x);
          order.setY(y);
          }
          }

          class Order {
          public void applyUpdate(ModifyRequest modification) {
          modification.applyTo(this);
          }
          }


          --- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@...> wrote:
          >
          > Stuart,
          >
          > I have a few thoughts on this.
          >
          > > 1. I could add a method to the domain object and for each
          > > child object from the root pass the DTO and have the object
          > > update itself:
          >
          > The only things that belong in your domain are terms from you UL. Also DTOs are not domain objects. They are anemic objects that help bridge physical tiers in separate processes. You could consider making your application layer service methods receive serialized domain command objects instead. But if you are tied to DTOs in the application layer, at a minimum you need to translate DTOs into domain objects (see below).
          >
          > > 2. I could create a command to wrap the DTO but IMHO this
          > > removes the business logic from the domain to the command
          > > and the functionality could be implemented in the
          > > XXXService.provideXXXFunctionality method
          >
          > If you create commands, don't make them DTO wrappers. Also, commands don't have to implement the mutation behavior on the aggregates. More often, IMO, a command tells the aggregate what to do and with what, but doesn't do the command.
          >
          > > 3. Visitor pattern? Same drawbacks as the command pattern
          >
          > Well, I think the behavior is better if implemented in the aggregate. But it might depend on the level of complexity.
          >
          > All the above considered, I wonder if your application service methods are revealing domain responsibilities. Remember that Domain Services are meant to deal with domain behavior that doesn't fit or belong on any one domain object (aggregate, entity, value, whatever). Rather the Domain Service orchestrates behaviors across multiple domain objects. So as your application service requests arrive, consider translating the DTOs into domain objects of some kind, either commands or value objects. Then invoke a Domain Service method, which as a receiver might be named closely to the application service sender, passing the translated parameters (command or value objects). That Domain Service would use Repositories to find aggregates that overlap in the use case / user story, and invoke command methods on those aggregates, passing the applicable parts of the parameter domain objects (commands or value objects). That will help correctly keep your application services thin and retain your business logic only in the core domain model.
          >
          > Vaughn
          >
          >
          >
          > --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@> wrote:
          > >
          > > Hi,
          > >
          > > My architecture is very simple. We have an entry point (service) into the system which receives a DTO:
          > >
          > > interface XXXService {
          > > void provideXXXFunctionality(XXXDTO dto);
          > > }
          > >
          > > These DTOs are then used to update domain objects. The DTO is complex and can update many objects under an aggregate root. How is the updating of the domain object best achieved?
          > >
          > > 1. I could add a method to the domain object and for each child object from the root pass the DTO and have the object update itself:
          > >
          > > class Domain {
          > > public void updateForXXX(XXXDTO dto);
          > > }
          > >
          > > But ideally I would like to keep the DTO out of the domain.
          > >
          > > 2. I could create a command to wrap the DTO but IMHO this removes the business logic from the domain to the command and the functionality could be implemented in the XXXService.provideXXXFunctionality method
          > >
          > > 3. Visitor pattern? Same drawbacks as the command pattern
          > >
          >
        • vvernon_shiftmethod
          I was indicating that you might have some terminology in your model, such as Change an Order , which would lead to creating the following domain command
          Message 4 of 21 , Jan 13, 2010
          View Source
          • 0 Attachment
            I was indicating that you might have some terminology in your model, such as "Change an Order", which would lead to creating the following domain command class:

            public class ChangeOrderCommand {...} // serializable

            Then on your Order class you have a method such as:

            public class Order {
            // ...
            public void change(ChangeOrderCommand aCommand) {
            // modify myself based on aCommand...
            }
            }

            How your ChangeOrderCommand is created doesn't matter. It might get populated by UI mappings, it might come in from a web service request, or whatever.

            If you are tied to using DTOs, then you would create a ChangeOrderCommand from your DTO attributes as you indicated below. But it would be unfortunate if you were required to use a DTO, because that's unnecessary complexity if you have domain commands.

            Vaughn


            --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@...> wrote:
            >
            > Here is a different example
            >
            > // domain object(s)
            > class Order {
            > // large number of properties
            > }
            >
            > class OrderLine {
            > Order createOrder(CreateOrderDTO dto);
            > }
            >
            > // dto (complex object)
            > class CreateOrderRequestDTO {
            > String orderType;
            > double qty;
            > .....
            > }
            >
            > How would you remove the DTO? I could replace it with another object (specification?) but that would have almost the same properties as the DTO.
            >
            > Here is another example:
            >
            > // dto
            > class ModifyOrderRequestDTO {
            > X x;
            > Y y;
            > }
            >
            > // domain object
            > class Order {
            > public void modify(ModifyOrderRequestDTO modification) {
            > setX(modification.x);
            > setY(modification.y);
            > }
            > }
            >
            > possible soln (doesn't appear to provide any benefits):
            >
            > class Transformer {
            > ModifyRequest transform(ModifyRequestDTO dto) {
            > return new ModifyRequest(dto.x, dto.y);
            > }
            > }
            >
            >
            > class ModifyRequest {
            > X x;
            > Y y;
            >
            > void applyTo(Order order) {
            > order.setX(x);
            > order.setY(y);
            > }
            > }
            >
            > class Order {
            > public void applyUpdate(ModifyRequest modification) {
            > modification.applyTo(this);
            > }
            > }
            >
            >
            > --- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@> wrote:
            > >
            > > Stuart,
            > >
            > > I have a few thoughts on this.
            > >
            > > > 1. I could add a method to the domain object and for each
            > > > child object from the root pass the DTO and have the object
            > > > update itself:
            > >
            > > The only things that belong in your domain are terms from you UL. Also DTOs are not domain objects. They are anemic objects that help bridge physical tiers in separate processes. You could consider making your application layer service methods receive serialized domain command objects instead. But if you are tied to DTOs in the application layer, at a minimum you need to translate DTOs into domain objects (see below).
            > >
            > > > 2. I could create a command to wrap the DTO but IMHO this
            > > > removes the business logic from the domain to the command
            > > > and the functionality could be implemented in the
            > > > XXXService.provideXXXFunctionality method
            > >
            > > If you create commands, don't make them DTO wrappers. Also, commands don't have to implement the mutation behavior on the aggregates. More often, IMO, a command tells the aggregate what to do and with what, but doesn't do the command.
            > >
            > > > 3. Visitor pattern? Same drawbacks as the command pattern
            > >
            > > Well, I think the behavior is better if implemented in the aggregate. But it might depend on the level of complexity.
            > >
            > > All the above considered, I wonder if your application service methods are revealing domain responsibilities. Remember that Domain Services are meant to deal with domain behavior that doesn't fit or belong on any one domain object (aggregate, entity, value, whatever). Rather the Domain Service orchestrates behaviors across multiple domain objects. So as your application service requests arrive, consider translating the DTOs into domain objects of some kind, either commands or value objects. Then invoke a Domain Service method, which as a receiver might be named closely to the application service sender, passing the translated parameters (command or value objects). That Domain Service would use Repositories to find aggregates that overlap in the use case / user story, and invoke command methods on those aggregates, passing the applicable parts of the parameter domain objects (commands or value objects). That will help correctly keep your application services thin and retain your business logic only in the core domain model.
            > >
            > > Vaughn
            > >
            > >
            > >
            > > --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@> wrote:
            > > >
            > > > Hi,
            > > >
            > > > My architecture is very simple. We have an entry point (service) into the system which receives a DTO:
            > > >
            > > > interface XXXService {
            > > > void provideXXXFunctionality(XXXDTO dto);
            > > > }
            > > >
            > > > These DTOs are then used to update domain objects. The DTO is complex and can update many objects under an aggregate root. How is the updating of the domain object best achieved?
            > > >
            > > > 1. I could add a method to the domain object and for each child object from the root pass the DTO and have the object update itself:
            > > >
            > > > class Domain {
            > > > public void updateForXXX(XXXDTO dto);
            > > > }
            > > >
            > > > But ideally I would like to keep the DTO out of the domain.
            > > >
            > > > 2. I could create a command to wrap the DTO but IMHO this removes the business logic from the domain to the command and the functionality could be implemented in the XXXService.provideXXXFunctionality method
            > > >
            > > > 3. Visitor pattern? Same drawbacks as the command pattern
            > > >
            > >
            >
          • Martin Nilsson
            Isn t the Command object just another name for the Dto in this example? I mean, the Command object is also anemic, it doesn t execute the command itself it
            Message 5 of 21 , Jan 13, 2010
            View Source
            • 0 Attachment
              Isn't the Command object just another name for the Dto in this example? I mean, the Command object is also anemic, it doesn't execute the command itself it just holds data.

              I'm trying to remove dto terminology from my design and create command messages (ChangeOrderMessage) which is then handled by a ChangeOrderHandler(of ChangeOrderMessage) which is the command in my opinion. The handler then sends domain messages to the domain, like ChangeDeliveryAddressMessage, AddProductMessage, etc which the Order class can handle.

              I'm still evaluating this approach so any opinions is appreciated.

              /martin

              On Thu, Jan 14, 2010 at 7:16 AM, vvernon_shiftmethod <vvernon@...> wrote:
               

              I was indicating that you might have some terminology in your model, such as "Change an Order", which would lead to creating the following domain command class:

              public class ChangeOrderCommand {...} // serializable

              Then on your Order class you have a method such as:

              public class Order {
              // ...
              public void change(ChangeOrderCommand aCommand) {
              // modify myself based on aCommand...
              }
              }

              How your ChangeOrderCommand is created doesn't matter. It might get populated by UI mappings, it might come in from a web service request, or whatever.

              If you are tied to using DTOs, then you would create a ChangeOrderCommand from your DTO attributes as you indicated below. But it would be unfortunate if you were required to use a DTO, because that's unnecessary complexity if you have domain commands.



              Vaughn

              --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@...> wrote:
              >
              > Here is a different example
              >
              > // domain object(s)
              > class Order {
              > // large number of properties
              > }
              >
              > class OrderLine {
              > Order createOrder(CreateOrderDTO dto);
              > }
              >
              > // dto (complex object)
              > class CreateOrderRequestDTO {
              > String orderType;
              > double qty;
              > .....
              > }
              >
              > How would you remove the DTO? I could replace it with another object (specification?) but that would have almost the same properties as the DTO.
              >
              > Here is another example:
              >
              > // dto
              > class ModifyOrderRequestDTO {
              > X x;
              > Y y;
              > }
              >
              > // domain object
              > class Order {
              > public void modify(ModifyOrderRequestDTO modification) {
              > setX(modification.x);
              > setY(modification.y);
              > }
              > }
              >
              > possible soln (doesn't appear to provide any benefits):
              >
              > class Transformer {
              > ModifyRequest transform(ModifyRequestDTO dto) {
              > return new ModifyRequest(dto.x, dto.y);
              > }
              > }
              >
              >
              > class ModifyRequest {
              > X x;
              > Y y;
              >
              > void applyTo(Order order) {
              > order.setX(x);
              > order.setY(y);
              > }
              > }
              >
              > class Order {
              > public void applyUpdate(ModifyRequest modification) {
              > modification.applyTo(this);
              > }
              > }
              >
              >
              > --- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@> wrote:
              > >
              > > Stuart,
              > >
              > > I have a few thoughts on this.
              > >
              > > > 1. I could add a method to the domain object and for each
              > > > child object from the root pass the DTO and have the object
              > > > update itself:
              > >
              > > The only things that belong in your domain are terms from you UL. Also DTOs are not domain objects. They are anemic objects that help bridge physical tiers in separate processes. You could consider making your application layer service methods receive serialized domain command objects instead. But if you are tied to DTOs in the application layer, at a minimum you need to translate DTOs into domain objects (see below).
              > >
              > > > 2. I could create a command to wrap the DTO but IMHO this
              > > > removes the business logic from the domain to the command
              > > > and the functionality could be implemented in the
              > > > XXXService.provideXXXFunctionality method
              > >
              > > If you create commands, don't make them DTO wrappers. Also, commands don't have to implement the mutation behavior on the aggregates. More often, IMO, a command tells the aggregate what to do and with what, but doesn't do the command.
              > >
              > > > 3. Visitor pattern? Same drawbacks as the command pattern
              > >
              > > Well, I think the behavior is better if implemented in the aggregate. But it might depend on the level of complexity.
              > >
              > > All the above considered, I wonder if your application service methods are revealing domain responsibilities. Remember that Domain Services are meant to deal with domain behavior that doesn't fit or belong on any one domain object (aggregate, entity, value, whatever). Rather the Domain Service orchestrates behaviors across multiple domain objects. So as your application service requests arrive, consider translating the DTOs into domain objects of some kind, either commands or value objects. Then invoke a Domain Service method, which as a receiver might be named closely to the application service sender, passing the translated parameters (command or value objects). That Domain Service would use Repositories to find aggregates that overlap in the use case / user story, and invoke command methods on those aggregates, passing the applicable parts of the parameter domain objects (commands or value objects). That will help correctly keep your application services thin and retain your business logic only in the core domain model.
              > >
              > > Vaughn
              > >
              > >
              > >
              > > --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@> wrote:
              > > >
              > > > Hi,
              > > >
              > > > My architecture is very simple. We have an entry point (service) into the system which receives a DTO:
              > > >
              > > > interface XXXService {
              > > > void provideXXXFunctionality(XXXDTO dto);
              > > > }
              > > >
              > > > These DTOs are then used to update domain objects. The DTO is complex and can update many objects under an aggregate root. How is the updating of the domain object best achieved?
              > > >
              > > > 1. I could add a method to the domain object and for each child object from the root pass the DTO and have the object update itself:
              > > >
              > > > class Domain {
              > > > public void updateForXXX(XXXDTO dto);
              > > > }
              > > >
              > > > But ideally I would like to keep the DTO out of the domain.
              > > >
              > > > 2. I could create a command to wrap the DTO but IMHO this removes the business logic from the domain to the command and the functionality could be implemented in the XXXService.provideXXXFunctionality method
              > > >
              > > > 3. Visitor pattern? Same drawbacks as the command pattern
              > > >
              > >
              >


            • Greg Young
              Generally I would recommend avoiding having the domain On Thu, Jan 14, 2010 at 8:16 AM, vvernon_shiftmethod
              Message 6 of 21 , Jan 14, 2010
              View Source
              • 0 Attachment
                Generally I would recommend avoiding having the domain 

                On Thu, Jan 14, 2010 at 8:16 AM, vvernon_shiftmethod <vvernon@...> wrote:
                 

                I was indicating that you might have some terminology in your model, such as "Change an Order", which would lead to creating the following domain command class:

                public class ChangeOrderCommand {...} // serializable

                Then on your Order class you have a method such as:

                public class Order {
                // ...
                public void change(ChangeOrderCommand aCommand) {
                // modify myself based on aCommand...
                }
                }

                How your ChangeOrderCommand is created doesn't matter. It might get populated by UI mappings, it might come in from a web service request, or whatever.

                If you are tied to using DTOs, then you would create a ChangeOrderCommand from your DTO attributes as you indicated below. But it would be unfortunate if you were required to use a DTO, because that's unnecessary complexity if you have domain commands.



                Vaughn

                --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@...> wrote:
                >
                > Here is a different example
                >
                > // domain object(s)
                > class Order {
                > // large number of properties
                > }
                >
                > class OrderLine {
                > Order createOrder(CreateOrderDTO dto);
                > }
                >
                > // dto (complex object)
                > class CreateOrderRequestDTO {
                > String orderType;
                > double qty;
                > .....
                > }
                >
                > How would you remove the DTO? I could replace it with another object (specification?) but that would have almost the same properties as the DTO.
                >
                > Here is another example:
                >
                > // dto
                > class ModifyOrderRequestDTO {
                > X x;
                > Y y;
                > }
                >
                > // domain object
                > class Order {
                > public void modify(ModifyOrderRequestDTO modification) {
                > setX(modification.x);
                > setY(modification.y);
                > }
                > }
                >
                > possible soln (doesn't appear to provide any benefits):
                >
                > class Transformer {
                > ModifyRequest transform(ModifyRequestDTO dto) {
                > return new ModifyRequest(dto.x, dto.y);
                > }
                > }
                >
                >
                > class ModifyRequest {
                > X x;
                > Y y;
                >
                > void applyTo(Order order) {
                > order.setX(x);
                > order.setY(y);
                > }
                > }
                >
                > class Order {
                > public void applyUpdate(ModifyRequest modification) {
                > modification.applyTo(this);
                > }
                > }
                >
                >
                > --- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@> wrote:
                > >
                > > Stuart,
                > >
                > > I have a few thoughts on this.
                > >
                > > > 1. I could add a method to the domain object and for each
                > > > child object from the root pass the DTO and have the object
                > > > update itself:
                > >
                > > The only things that belong in your domain are terms from you UL. Also DTOs are not domain objects. They are anemic objects that help bridge physical tiers in separate processes. You could consider making your application layer service methods receive serialized domain command objects instead. But if you are tied to DTOs in the application layer, at a minimum you need to translate DTOs into domain objects (see below).
                > >
                > > > 2. I could create a command to wrap the DTO but IMHO this
                > > > removes the business logic from the domain to the command
                > > > and the functionality could be implemented in the
                > > > XXXService.provideXXXFunctionality method
                > >
                > > If you create commands, don't make them DTO wrappers. Also, commands don't have to implement the mutation behavior on the aggregates. More often, IMO, a command tells the aggregate what to do and with what, but doesn't do the command.
                > >
                > > > 3. Visitor pattern? Same drawbacks as the command pattern
                > >
                > > Well, I think the behavior is better if implemented in the aggregate. But it might depend on the level of complexity.
                > >
                > > All the above considered, I wonder if your application service methods are revealing domain responsibilities. Remember that Domain Services are meant to deal with domain behavior that doesn't fit or belong on any one domain object (aggregate, entity, value, whatever). Rather the Domain Service orchestrates behaviors across multiple domain objects. So as your application service requests arrive, consider translating the DTOs into domain objects of some kind, either commands or value objects. Then invoke a Domain Service method, which as a receiver might be named closely to the application service sender, passing the translated parameters (command or value objects). That Domain Service would use Repositories to find aggregates that overlap in the use case / user story, and invoke command methods on those aggregates, passing the applicable parts of the parameter domain objects (commands or value objects). That will help correctly keep your application services thin and retain your business logic only in the core domain model.
                > >
                > > Vaughn
                > >
                > >
                > >
                > > --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@> wrote:
                > > >
                > > > Hi,
                > > >
                > > > My architecture is very simple. We have an entry point (service) into the system which receives a DTO:
                > > >
                > > > interface XXXService {
                > > > void provideXXXFunctionality(XXXDTO dto);
                > > > }
                > > >
                > > > These DTOs are then used to update domain objects. The DTO is complex and can update many objects under an aggregate root. How is the updating of the domain object best achieved?
                > > >
                > > > 1. I could add a method to the domain object and for each child object from the root pass the DTO and have the object update itself:
                > > >
                > > > class Domain {
                > > > public void updateForXXX(XXXDTO dto);
                > > > }
                > > >
                > > > But ideally I would like to keep the DTO out of the domain.
                > > >
                > > > 2. I could create a command to wrap the DTO but IMHO this removes the business logic from the domain to the command and the functionality could be implemented in the XXXService.provideXXXFunctionality method
                > > >
                > > > 3. Visitor pattern? Same drawbacks as the command pattern
                > > >
                > >
                >




                --
                Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de votre attention
              • vvernon_shiftmethod
                ... A Command might be anemic, but it is not the same as a DTO. For one thing a DTO is a different pattern. DTOs are not about the domain model and should not
                Message 7 of 21 , Jan 14, 2010
                View Source
                • 0 Attachment
                  > Isn't the Command object just another name for the Dto
                  > in this example? I mean, the Command object is also
                  > anemic, it doesn't execute the command itself it just
                  > holds data.

                  A Command might be anemic, but it is not the same as a DTO. For one thing a DTO is a different pattern. DTOs are not about the domain model and should not live in or be referenced by the model. Another thing is that the Command might hold hints about how the attributes/properties it holds are to be used.

                  Also, there is nothing that says the Command could not have some behavior. (I think there are more options for how Commands can be used in Java than in C# because of Java package and class scoping rules vs C# namespace and class scoping rules.)

                  Vaughn


                  --- In domaindrivendesign@yahoogroups.com, Martin Nilsson <mffmartin@...> wrote:
                  >
                  > Isn't the Command object just another name for the Dto in this example? I
                  > mean, the Command object is also anemic, it doesn't execute the command
                  > itself it just holds data.
                  >
                  > I'm trying to remove dto terminology from my design and create command
                  > messages (ChangeOrderMessage) which is then handled by a
                  > ChangeOrderHandler(of ChangeOrderMessage) which is the command in my
                  > opinion. The handler then sends domain messages to the domain, like
                  > ChangeDeliveryAddressMessage, AddProductMessage, etc which the Order class
                  > can handle.
                  >
                  > I'm still evaluating this approach so any opinions is appreciated.
                  >
                  > /martin
                  >
                  > On Thu, Jan 14, 2010 at 7:16 AM, vvernon_shiftmethod <
                  > vvernon@...> wrote:
                  >
                  > >
                  > >
                  > > I was indicating that you might have some terminology in your model, such
                  > > as "Change an Order", which would lead to creating the following domain
                  > > command class:
                  > >
                  > > public class ChangeOrderCommand {...} // serializable
                  > >
                  > > Then on your Order class you have a method such as:
                  > >
                  > > public class Order {
                  > > // ...
                  > > public void change(ChangeOrderCommand aCommand) {
                  > > // modify myself based on aCommand...
                  > > }
                  > > }
                  > >
                  > > How your ChangeOrderCommand is created doesn't matter. It might get
                  > > populated by UI mappings, it might come in from a web service request, or
                  > > whatever.
                  > >
                  > > If you are tied to using DTOs, then you would create a ChangeOrderCommand
                  > > from your DTO attributes as you indicated below. But it would be unfortunate
                  > > if you were required to use a DTO, because that's unnecessary complexity if
                  > > you have domain commands.
                  > >
                  > >
                  > > Vaughn
                  > >
                  > > --- In domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,
                  > > "stuart_faircloth" <stuart_faircloth@> wrote:
                  > > >
                  > > > Here is a different example
                  > > >
                  > > > // domain object(s)
                  > > > class Order {
                  > > > // large number of properties
                  > > > }
                  > > >
                  > > > class OrderLine {
                  > > > Order createOrder(CreateOrderDTO dto);
                  > > > }
                  > > >
                  > > > // dto (complex object)
                  > > > class CreateOrderRequestDTO {
                  > > > String orderType;
                  > > > double qty;
                  > > > .....
                  > > > }
                  > > >
                  > > > How would you remove the DTO? I could replace it with another object
                  > > (specification?) but that would have almost the same properties as the DTO.
                  > > >
                  > > > Here is another example:
                  > > >
                  > > > // dto
                  > > > class ModifyOrderRequestDTO {
                  > > > X x;
                  > > > Y y;
                  > > > }
                  > > >
                  > > > // domain object
                  > > > class Order {
                  > > > public void modify(ModifyOrderRequestDTO modification) {
                  > > > setX(modification.x);
                  > > > setY(modification.y);
                  > > > }
                  > > > }
                  > > >
                  > > > possible soln (doesn't appear to provide any benefits):
                  > > >
                  > > > class Transformer {
                  > > > ModifyRequest transform(ModifyRequestDTO dto) {
                  > > > return new ModifyRequest(dto.x, dto.y);
                  > > > }
                  > > > }
                  > > >
                  > > >
                  > > > class ModifyRequest {
                  > > > X x;
                  > > > Y y;
                  > > >
                  > > > void applyTo(Order order) {
                  > > > order.setX(x);
                  > > > order.setY(y);
                  > > > }
                  > > > }
                  > > >
                  > > > class Order {
                  > > > public void applyUpdate(ModifyRequest modification) {
                  > > > modification.applyTo(this);
                  > > > }
                  > > > }
                  > > >
                  > > >
                  > > > --- In domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,
                  > > "vvernon_shiftmethod" <vvernon@> wrote:
                  > > > >
                  > > > > Stuart,
                  > > > >
                  > > > > I have a few thoughts on this.
                  > > > >
                  > > > > > 1. I could add a method to the domain object and for each
                  > > > > > child object from the root pass the DTO and have the object
                  > > > > > update itself:
                  > > > >
                  > > > > The only things that belong in your domain are terms from you UL. Also
                  > > DTOs are not domain objects. They are anemic objects that help bridge
                  > > physical tiers in separate processes. You could consider making your
                  > > application layer service methods receive serialized domain command objects
                  > > instead. But if you are tied to DTOs in the application layer, at a minimum
                  > > you need to translate DTOs into domain objects (see below).
                  > > > >
                  > > > > > 2. I could create a command to wrap the DTO but IMHO this
                  > > > > > removes the business logic from the domain to the command
                  > > > > > and the functionality could be implemented in the
                  > > > > > XXXService.provideXXXFunctionality method
                  > > > >
                  > > > > If you create commands, don't make them DTO wrappers. Also, commands
                  > > don't have to implement the mutation behavior on the aggregates. More often,
                  > > IMO, a command tells the aggregate what to do and with what, but doesn't do
                  > > the command.
                  > > > >
                  > > > > > 3. Visitor pattern? Same drawbacks as the command pattern
                  > > > >
                  > > > > Well, I think the behavior is better if implemented in the aggregate.
                  > > But it might depend on the level of complexity.
                  > > > >
                  > > > > All the above considered, I wonder if your application service methods
                  > > are revealing domain responsibilities. Remember that Domain Services are
                  > > meant to deal with domain behavior that doesn't fit or belong on any one
                  > > domain object (aggregate, entity, value, whatever). Rather the Domain
                  > > Service orchestrates behaviors across multiple domain objects. So as your
                  > > application service requests arrive, consider translating the DTOs into
                  > > domain objects of some kind, either commands or value objects. Then invoke a
                  > > Domain Service method, which as a receiver might be named closely to the
                  > > application service sender, passing the translated parameters (command or
                  > > value objects). That Domain Service would use Repositories to find
                  > > aggregates that overlap in the use case / user story, and invoke command
                  > > methods on those aggregates, passing the applicable parts of the parameter
                  > > domain objects (commands or value objects). That will help correctly keep
                  > > your application services thin and retain your business logic only in the
                  > > core domain model.
                  > > > >
                  > > > > Vaughn
                  > > > >
                  > > > >
                  > > > >
                  > > > > --- In domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,
                  > > "stuart_faircloth" <stuart_faircloth@> wrote:
                  > > > > >
                  > > > > > Hi,
                  > > > > >
                  > > > > > My architecture is very simple. We have an entry point (service) into
                  > > the system which receives a DTO:
                  > > > > >
                  > > > > > interface XXXService {
                  > > > > > void provideXXXFunctionality(XXXDTO dto);
                  > > > > > }
                  > > > > >
                  > > > > > These DTOs are then used to update domain objects. The DTO is complex
                  > > and can update many objects under an aggregate root. How is the updating of
                  > > the domain object best achieved?
                  > > > > >
                  > > > > > 1. I could add a method to the domain object and for each child
                  > > object from the root pass the DTO and have the object update itself:
                  > > > > >
                  > > > > > class Domain {
                  > > > > > public void updateForXXX(XXXDTO dto);
                  > > > > > }
                  > > > > >
                  > > > > > But ideally I would like to keep the DTO out of the domain.
                  > > > > >
                  > > > > > 2. I could create a command to wrap the DTO but IMHO this removes the
                  > > business logic from the domain to the command and the functionality could be
                  > > implemented in the XXXService.provideXXXFunctionality method
                  > > > > >
                  > > > > > 3. Visitor pattern? Same drawbacks as the command pattern
                  > > > > >
                  > > > >
                  > > >
                  > >
                  > >
                  > >
                  >
                • vvernon_shiftmethod
                  I don t understand.
                  Message 8 of 21 , Jan 14, 2010
                  View Source
                  • 0 Attachment
                    I don't understand.


                    --- In domaindrivendesign@yahoogroups.com, Greg Young <gregoryyoung1@...> wrote:
                    >
                    > Generally I would recommend avoiding having the domain
                    >
                    > On Thu, Jan 14, 2010 at 8:16 AM, vvernon_shiftmethod <
                    > vvernon@...> wrote:
                    >
                    > >
                    > >
                    > > I was indicating that you might have some terminology in your model, such
                    > > as "Change an Order", which would lead to creating the following domain
                    > > command class:
                    > >
                    > > public class ChangeOrderCommand {...} // serializable
                    > >
                    > > Then on your Order class you have a method such as:
                    > >
                    > > public class Order {
                    > > // ...
                    > > public void change(ChangeOrderCommand aCommand) {
                    > > // modify myself based on aCommand...
                    > > }
                    > > }
                    > >
                    > > How your ChangeOrderCommand is created doesn't matter. It might get
                    > > populated by UI mappings, it might come in from a web service request, or
                    > > whatever.
                    > >
                    > > If you are tied to using DTOs, then you would create a ChangeOrderCommand
                    > > from your DTO attributes as you indicated below. But it would be unfortunate
                    > > if you were required to use a DTO, because that's unnecessary complexity if
                    > > you have domain commands.
                    > >
                    > >
                    > > Vaughn
                    > >
                    > > --- In domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,
                    > > "stuart_faircloth" <stuart_faircloth@> wrote:
                    > > >
                    > > > Here is a different example
                    > > >
                    > > > // domain object(s)
                    > > > class Order {
                    > > > // large number of properties
                    > > > }
                    > > >
                    > > > class OrderLine {
                    > > > Order createOrder(CreateOrderDTO dto);
                    > > > }
                    > > >
                    > > > // dto (complex object)
                    > > > class CreateOrderRequestDTO {
                    > > > String orderType;
                    > > > double qty;
                    > > > .....
                    > > > }
                    > > >
                    > > > How would you remove the DTO? I could replace it with another object
                    > > (specification?) but that would have almost the same properties as the DTO.
                    > > >
                    > > > Here is another example:
                    > > >
                    > > > // dto
                    > > > class ModifyOrderRequestDTO {
                    > > > X x;
                    > > > Y y;
                    > > > }
                    > > >
                    > > > // domain object
                    > > > class Order {
                    > > > public void modify(ModifyOrderRequestDTO modification) {
                    > > > setX(modification.x);
                    > > > setY(modification.y);
                    > > > }
                    > > > }
                    > > >
                    > > > possible soln (doesn't appear to provide any benefits):
                    > > >
                    > > > class Transformer {
                    > > > ModifyRequest transform(ModifyRequestDTO dto) {
                    > > > return new ModifyRequest(dto.x, dto.y);
                    > > > }
                    > > > }
                    > > >
                    > > >
                    > > > class ModifyRequest {
                    > > > X x;
                    > > > Y y;
                    > > >
                    > > > void applyTo(Order order) {
                    > > > order.setX(x);
                    > > > order.setY(y);
                    > > > }
                    > > > }
                    > > >
                    > > > class Order {
                    > > > public void applyUpdate(ModifyRequest modification) {
                    > > > modification.applyTo(this);
                    > > > }
                    > > > }
                    > > >
                    > > >
                    > > > --- In domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,
                    > > "vvernon_shiftmethod" <vvernon@> wrote:
                    > > > >
                    > > > > Stuart,
                    > > > >
                    > > > > I have a few thoughts on this.
                    > > > >
                    > > > > > 1. I could add a method to the domain object and for each
                    > > > > > child object from the root pass the DTO and have the object
                    > > > > > update itself:
                    > > > >
                    > > > > The only things that belong in your domain are terms from you UL. Also
                    > > DTOs are not domain objects. They are anemic objects that help bridge
                    > > physical tiers in separate processes. You could consider making your
                    > > application layer service methods receive serialized domain command objects
                    > > instead. But if you are tied to DTOs in the application layer, at a minimum
                    > > you need to translate DTOs into domain objects (see below).
                    > > > >
                    > > > > > 2. I could create a command to wrap the DTO but IMHO this
                    > > > > > removes the business logic from the domain to the command
                    > > > > > and the functionality could be implemented in the
                    > > > > > XXXService.provideXXXFunctionality method
                    > > > >
                    > > > > If you create commands, don't make them DTO wrappers. Also, commands
                    > > don't have to implement the mutation behavior on the aggregates. More often,
                    > > IMO, a command tells the aggregate what to do and with what, but doesn't do
                    > > the command.
                    > > > >
                    > > > > > 3. Visitor pattern? Same drawbacks as the command pattern
                    > > > >
                    > > > > Well, I think the behavior is better if implemented in the aggregate.
                    > > But it might depend on the level of complexity.
                    > > > >
                    > > > > All the above considered, I wonder if your application service methods
                    > > are revealing domain responsibilities. Remember that Domain Services are
                    > > meant to deal with domain behavior that doesn't fit or belong on any one
                    > > domain object (aggregate, entity, value, whatever). Rather the Domain
                    > > Service orchestrates behaviors across multiple domain objects. So as your
                    > > application service requests arrive, consider translating the DTOs into
                    > > domain objects of some kind, either commands or value objects. Then invoke a
                    > > Domain Service method, which as a receiver might be named closely to the
                    > > application service sender, passing the translated parameters (command or
                    > > value objects). That Domain Service would use Repositories to find
                    > > aggregates that overlap in the use case / user story, and invoke command
                    > > methods on those aggregates, passing the applicable parts of the parameter
                    > > domain objects (commands or value objects). That will help correctly keep
                    > > your application services thin and retain your business logic only in the
                    > > core domain model.
                    > > > >
                    > > > > Vaughn
                    > > > >
                    > > > >
                    > > > >
                    > > > > --- In domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,
                    > > "stuart_faircloth" <stuart_faircloth@> wrote:
                    > > > > >
                    > > > > > Hi,
                    > > > > >
                    > > > > > My architecture is very simple. We have an entry point (service) into
                    > > the system which receives a DTO:
                    > > > > >
                    > > > > > interface XXXService {
                    > > > > > void provideXXXFunctionality(XXXDTO dto);
                    > > > > > }
                    > > > > >
                    > > > > > These DTOs are then used to update domain objects. The DTO is complex
                    > > and can update many objects under an aggregate root. How is the updating of
                    > > the domain object best achieved?
                    > > > > >
                    > > > > > 1. I could add a method to the domain object and for each child
                    > > object from the root pass the DTO and have the object update itself:
                    > > > > >
                    > > > > > class Domain {
                    > > > > > public void updateForXXX(XXXDTO dto);
                    > > > > > }
                    > > > > >
                    > > > > > But ideally I would like to keep the DTO out of the domain.
                    > > > > >
                    > > > > > 2. I could create a command to wrap the DTO but IMHO this removes the
                    > > business logic from the domain to the command and the functionality could be
                    > > implemented in the XXXService.provideXXXFunctionality method
                    > > > > >
                    > > > > > 3. Visitor pattern? Same drawbacks as the command pattern
                    > > > > >
                    > > > >
                    > > >
                    > >
                    > >
                    > >
                    >
                    >
                    >
                    > --
                    > Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de
                    > votre attention
                    >
                  • Greg Young
                    Generally I would avoid having the domain directly access the commands but would instead have the mapping logic likely in the command handler. there are
                    Message 9 of 21 , Jan 14, 2010
                    View Source
                    • 0 Attachment
                      Generally I would avoid having the domain directly access the commands but would instead have the mapping logic likely in the command handler. there are however times when the coupling can be acceptable

                      On Thu, Jan 14, 2010 at 8:16 AM, vvernon_shiftmethod <vvernon@...> wrote:
                       

                      I was indicating that you might have some terminology in your model, such as "Change an Order", which would lead to creating the following domain command class:

                      public class ChangeOrderCommand {...} // serializable

                      Then on your Order class you have a method such as:

                      public class Order {
                      // ...
                      public void change(ChangeOrderCommand aCommand) {
                      // modify myself based on aCommand...
                      }
                      }

                      How your ChangeOrderCommand is created doesn't matter. It might get populated by UI mappings, it might come in from a web service request, or whatever.

                      If you are tied to using DTOs, then you would create a ChangeOrderCommand from your DTO attributes as you indicated below. But it would be unfortunate if you were required to use a DTO, because that's unnecessary complexity if you have domain commands.



                      Vaughn

                      --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@...> wrote:
                      >
                      > Here is a different example
                      >
                      > // domain object(s)
                      > class Order {
                      > // large number of properties
                      > }
                      >
                      > class OrderLine {
                      > Order createOrder(CreateOrderDTO dto);
                      > }
                      >
                      > // dto (complex object)
                      > class CreateOrderRequestDTO {
                      > String orderType;
                      > double qty;
                      > .....
                      > }
                      >
                      > How would you remove the DTO? I could replace it with another object (specification?) but that would have almost the same properties as the DTO.
                      >
                      > Here is another example:
                      >
                      > // dto
                      > class ModifyOrderRequestDTO {
                      > X x;
                      > Y y;
                      > }
                      >
                      > // domain object
                      > class Order {
                      > public void modify(ModifyOrderRequestDTO modification) {
                      > setX(modification.x);
                      > setY(modification.y);
                      > }
                      > }
                      >
                      > possible soln (doesn't appear to provide any benefits):
                      >
                      > class Transformer {
                      > ModifyRequest transform(ModifyRequestDTO dto) {
                      > return new ModifyRequest(dto.x, dto.y);
                      > }
                      > }
                      >
                      >
                      > class ModifyRequest {
                      > X x;
                      > Y y;
                      >
                      > void applyTo(Order order) {
                      > order.setX(x);
                      > order.setY(y);
                      > }
                      > }
                      >
                      > class Order {
                      > public void applyUpdate(ModifyRequest modification) {
                      > modification.applyTo(this);
                      > }
                      > }
                      >
                      >
                      > --- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@> wrote:
                      > >
                      > > Stuart,
                      > >
                      > > I have a few thoughts on this.
                      > >
                      > > > 1. I could add a method to the domain object and for each
                      > > > child object from the root pass the DTO and have the object
                      > > > update itself:
                      > >
                      > > The only things that belong in your domain are terms from you UL. Also DTOs are not domain objects. They are anemic objects that help bridge physical tiers in separate processes. You could consider making your application layer service methods receive serialized domain command objects instead. But if you are tied to DTOs in the application layer, at a minimum you need to translate DTOs into domain objects (see below).
                      > >
                      > > > 2. I could create a command to wrap the DTO but IMHO this
                      > > > removes the business logic from the domain to the command
                      > > > and the functionality could be implemented in the
                      > > > XXXService.provideXXXFunctionality method
                      > >
                      > > If you create commands, don't make them DTO wrappers. Also, commands don't have to implement the mutation behavior on the aggregates. More often, IMO, a command tells the aggregate what to do and with what, but doesn't do the command.
                      > >
                      > > > 3. Visitor pattern? Same drawbacks as the command pattern
                      > >
                      > > Well, I think the behavior is better if implemented in the aggregate. But it might depend on the level of complexity.
                      > >
                      > > All the above considered, I wonder if your application service methods are revealing domain responsibilities. Remember that Domain Services are meant to deal with domain behavior that doesn't fit or belong on any one domain object (aggregate, entity, value, whatever). Rather the Domain Service orchestrates behaviors across multiple domain objects. So as your application service requests arrive, consider translating the DTOs into domain objects of some kind, either commands or value objects. Then invoke a Domain Service method, which as a receiver might be named closely to the application service sender, passing the translated parameters (command or value objects). That Domain Service would use Repositories to find aggregates that overlap in the use case / user story, and invoke command methods on those aggregates, passing the applicable parts of the parameter domain objects (commands or value objects). That will help correctly keep your application services thin and retain your business logic only in the core domain model.
                      > >
                      > > Vaughn
                      > >
                      > >
                      > >
                      > > --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@> wrote:
                      > > >
                      > > > Hi,
                      > > >
                      > > > My architecture is very simple. We have an entry point (service) into the system which receives a DTO:
                      > > >
                      > > > interface XXXService {
                      > > > void provideXXXFunctionality(XXXDTO dto);
                      > > > }
                      > > >
                      > > > These DTOs are then used to update domain objects. The DTO is complex and can update many objects under an aggregate root. How is the updating of the domain object best achieved?
                      > > >
                      > > > 1. I could add a method to the domain object and for each child object from the root pass the DTO and have the object update itself:
                      > > >
                      > > > class Domain {
                      > > > public void updateForXXX(XXXDTO dto);
                      > > > }
                      > > >
                      > > > But ideally I would like to keep the DTO out of the domain.
                      > > >
                      > > > 2. I could create a command to wrap the DTO but IMHO this removes the business logic from the domain to the command and the functionality could be implemented in the XXXService.provideXXXFunctionality method
                      > > >
                      > > > 3. Visitor pattern? Same drawbacks as the command pattern
                      > > >
                      > >
                      >




                      --
                      Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de votre attention
                    • vvernon_shiftmethod
                      We might be using Commands a little differently. I am not doing CQRS. But would you mind providing a brief example of how you would do what you describe?
                      Message 10 of 21 , Jan 14, 2010
                      View Source
                      • 0 Attachment
                        We might be using Commands a little differently. I am not doing CQRS. But would you mind providing a brief example of how you would do what you describe?

                        Vaughn


                        --- In domaindrivendesign@yahoogroups.com, Greg Young <gregoryyoung1@...> wrote:
                        >
                        > Generally I would avoid having the domain directly access the commands but
                        > would instead have the mapping logic likely in the command handler. there
                        > are however times when the coupling can be acceptable
                        >
                        > On Thu, Jan 14, 2010 at 8:16 AM, vvernon_shiftmethod <
                        > vvernon@...> wrote:
                        >
                        > >
                        > >
                        > > I was indicating that you might have some terminology in your model, such
                        > > as "Change an Order", which would lead to creating the following domain
                        > > command class:
                        > >
                        > > public class ChangeOrderCommand {...} // serializable
                        > >
                        > > Then on your Order class you have a method such as:
                        > >
                        > > public class Order {
                        > > // ...
                        > > public void change(ChangeOrderCommand aCommand) {
                        > > // modify myself based on aCommand...
                        > > }
                        > > }
                        > >
                        > > How your ChangeOrderCommand is created doesn't matter. It might get
                        > > populated by UI mappings, it might come in from a web service request, or
                        > > whatever.
                        > >
                        > > If you are tied to using DTOs, then you would create a ChangeOrderCommand
                        > > from your DTO attributes as you indicated below. But it would be unfortunate
                        > > if you were required to use a DTO, because that's unnecessary complexity if
                        > > you have domain commands.
                        > >
                        > >
                        > > Vaughn
                        > >
                        > > --- In domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,
                        > > "stuart_faircloth" <stuart_faircloth@> wrote:
                        > > >
                        > > > Here is a different example
                        > > >
                        > > > // domain object(s)
                        > > > class Order {
                        > > > // large number of properties
                        > > > }
                        > > >
                        > > > class OrderLine {
                        > > > Order createOrder(CreateOrderDTO dto);
                        > > > }
                        > > >
                        > > > // dto (complex object)
                        > > > class CreateOrderRequestDTO {
                        > > > String orderType;
                        > > > double qty;
                        > > > .....
                        > > > }
                        > > >
                        > > > How would you remove the DTO? I could replace it with another object
                        > > (specification?) but that would have almost the same properties as the DTO.
                        > > >
                        > > > Here is another example:
                        > > >
                        > > > // dto
                        > > > class ModifyOrderRequestDTO {
                        > > > X x;
                        > > > Y y;
                        > > > }
                        > > >
                        > > > // domain object
                        > > > class Order {
                        > > > public void modify(ModifyOrderRequestDTO modification) {
                        > > > setX(modification.x);
                        > > > setY(modification.y);
                        > > > }
                        > > > }
                        > > >
                        > > > possible soln (doesn't appear to provide any benefits):
                        > > >
                        > > > class Transformer {
                        > > > ModifyRequest transform(ModifyRequestDTO dto) {
                        > > > return new ModifyRequest(dto.x, dto.y);
                        > > > }
                        > > > }
                        > > >
                        > > >
                        > > > class ModifyRequest {
                        > > > X x;
                        > > > Y y;
                        > > >
                        > > > void applyTo(Order order) {
                        > > > order.setX(x);
                        > > > order.setY(y);
                        > > > }
                        > > > }
                        > > >
                        > > > class Order {
                        > > > public void applyUpdate(ModifyRequest modification) {
                        > > > modification.applyTo(this);
                        > > > }
                        > > > }
                        > > >
                        > > >
                        > > > --- In domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,
                        > > "vvernon_shiftmethod" <vvernon@> wrote:
                        > > > >
                        > > > > Stuart,
                        > > > >
                        > > > > I have a few thoughts on this.
                        > > > >
                        > > > > > 1. I could add a method to the domain object and for each
                        > > > > > child object from the root pass the DTO and have the object
                        > > > > > update itself:
                        > > > >
                        > > > > The only things that belong in your domain are terms from you UL. Also
                        > > DTOs are not domain objects. They are anemic objects that help bridge
                        > > physical tiers in separate processes. You could consider making your
                        > > application layer service methods receive serialized domain command objects
                        > > instead. But if you are tied to DTOs in the application layer, at a minimum
                        > > you need to translate DTOs into domain objects (see below).
                        > > > >
                        > > > > > 2. I could create a command to wrap the DTO but IMHO this
                        > > > > > removes the business logic from the domain to the command
                        > > > > > and the functionality could be implemented in the
                        > > > > > XXXService.provideXXXFunctionality method
                        > > > >
                        > > > > If you create commands, don't make them DTO wrappers. Also, commands
                        > > don't have to implement the mutation behavior on the aggregates. More often,
                        > > IMO, a command tells the aggregate what to do and with what, but doesn't do
                        > > the command.
                        > > > >
                        > > > > > 3. Visitor pattern? Same drawbacks as the command pattern
                        > > > >
                        > > > > Well, I think the behavior is better if implemented in the aggregate.
                        > > But it might depend on the level of complexity.
                        > > > >
                        > > > > All the above considered, I wonder if your application service methods
                        > > are revealing domain responsibilities. Remember that Domain Services are
                        > > meant to deal with domain behavior that doesn't fit or belong on any one
                        > > domain object (aggregate, entity, value, whatever). Rather the Domain
                        > > Service orchestrates behaviors across multiple domain objects. So as your
                        > > application service requests arrive, consider translating the DTOs into
                        > > domain objects of some kind, either commands or value objects. Then invoke a
                        > > Domain Service method, which as a receiver might be named closely to the
                        > > application service sender, passing the translated parameters (command or
                        > > value objects). That Domain Service would use Repositories to find
                        > > aggregates that overlap in the use case / user story, and invoke command
                        > > methods on those aggregates, passing the applicable parts of the parameter
                        > > domain objects (commands or value objects). That will help correctly keep
                        > > your application services thin and retain your business logic only in the
                        > > core domain model.
                        > > > >
                        > > > > Vaughn
                        > > > >
                        > > > >
                        > > > >
                        > > > > --- In domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,
                        > > "stuart_faircloth" <stuart_faircloth@> wrote:
                        > > > > >
                        > > > > > Hi,
                        > > > > >
                        > > > > > My architecture is very simple. We have an entry point (service) into
                        > > the system which receives a DTO:
                        > > > > >
                        > > > > > interface XXXService {
                        > > > > > void provideXXXFunctionality(XXXDTO dto);
                        > > > > > }
                        > > > > >
                        > > > > > These DTOs are then used to update domain objects. The DTO is complex
                        > > and can update many objects under an aggregate root. How is the updating of
                        > > the domain object best achieved?
                        > > > > >
                        > > > > > 1. I could add a method to the domain object and for each child
                        > > object from the root pass the DTO and have the object update itself:
                        > > > > >
                        > > > > > class Domain {
                        > > > > > public void updateForXXX(XXXDTO dto);
                        > > > > > }
                        > > > > >
                        > > > > > But ideally I would like to keep the DTO out of the domain.
                        > > > > >
                        > > > > > 2. I could create a command to wrap the DTO but IMHO this removes the
                        > > business logic from the domain to the command and the functionality could be
                        > > implemented in the XXXService.provideXXXFunctionality method
                        > > > > >
                        > > > > > 3. Visitor pattern? Same drawbacks as the command pattern
                        > > > > >
                        > > > >
                        > > >
                        > >
                        > >
                        > >
                        >
                        >
                        >
                        > --
                        > Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de
                        > votre attention
                        >
                      • vvernon_shiftmethod
                        BTW, I don t consider the coupling a problem because the Commands live in the same Module with the Aggregate they are used by. Also this reflects what I posted
                        Message 11 of 21 , Jan 14, 2010
                        View Source
                        • 0 Attachment
                          BTW, I don't consider the coupling a problem because the Commands live in the same Module with the Aggregate they are used by.

                          Also this reflects what I posted around a year ago on the topic of "Editing Domain Model." I recall that you replied somewhere along the thread and indicated that you had previously used the same pattern.

                          It's pretty late here... will check back when the sun rises.

                          Vaughn


                          --- In domaindrivendesign@yahoogroups.com, Greg Young <gregoryyoung1@...> wrote:
                          >
                          > Generally I would avoid having the domain directly access the commands but
                          > would instead have the mapping logic likely in the command handler. there
                          > are however times when the coupling can be acceptable
                          >
                          > On Thu, Jan 14, 2010 at 8:16 AM, vvernon_shiftmethod <
                          > vvernon@...> wrote:
                          >
                          > >
                          > >
                          > > I was indicating that you might have some terminology in your model, such
                          > > as "Change an Order", which would lead to creating the following domain
                          > > command class:
                          > >
                          > > public class ChangeOrderCommand {...} // serializable
                          > >
                          > > Then on your Order class you have a method such as:
                          > >
                          > > public class Order {
                          > > // ...
                          > > public void change(ChangeOrderCommand aCommand) {
                          > > // modify myself based on aCommand...
                          > > }
                          > > }
                          > >
                          > > How your ChangeOrderCommand is created doesn't matter. It might get
                          > > populated by UI mappings, it might come in from a web service request, or
                          > > whatever.
                          > >
                          > > If you are tied to using DTOs, then you would create a ChangeOrderCommand
                          > > from your DTO attributes as you indicated below. But it would be unfortunate
                          > > if you were required to use a DTO, because that's unnecessary complexity if
                          > > you have domain commands.
                          > >
                          > >
                          > > Vaughn
                          > >
                          > > --- In domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,
                          > > "stuart_faircloth" <stuart_faircloth@> wrote:
                          > > >
                          > > > Here is a different example
                          > > >
                          > > > // domain object(s)
                          > > > class Order {
                          > > > // large number of properties
                          > > > }
                          > > >
                          > > > class OrderLine {
                          > > > Order createOrder(CreateOrderDTO dto);
                          > > > }
                          > > >
                          > > > // dto (complex object)
                          > > > class CreateOrderRequestDTO {
                          > > > String orderType;
                          > > > double qty;
                          > > > .....
                          > > > }
                          > > >
                          > > > How would you remove the DTO? I could replace it with another object
                          > > (specification?) but that would have almost the same properties as the DTO.
                          > > >
                          > > > Here is another example:
                          > > >
                          > > > // dto
                          > > > class ModifyOrderRequestDTO {
                          > > > X x;
                          > > > Y y;
                          > > > }
                          > > >
                          > > > // domain object
                          > > > class Order {
                          > > > public void modify(ModifyOrderRequestDTO modification) {
                          > > > setX(modification.x);
                          > > > setY(modification.y);
                          > > > }
                          > > > }
                          > > >
                          > > > possible soln (doesn't appear to provide any benefits):
                          > > >
                          > > > class Transformer {
                          > > > ModifyRequest transform(ModifyRequestDTO dto) {
                          > > > return new ModifyRequest(dto.x, dto.y);
                          > > > }
                          > > > }
                          > > >
                          > > >
                          > > > class ModifyRequest {
                          > > > X x;
                          > > > Y y;
                          > > >
                          > > > void applyTo(Order order) {
                          > > > order.setX(x);
                          > > > order.setY(y);
                          > > > }
                          > > > }
                          > > >
                          > > > class Order {
                          > > > public void applyUpdate(ModifyRequest modification) {
                          > > > modification.applyTo(this);
                          > > > }
                          > > > }
                          > > >
                          > > >
                          > > > --- In domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,
                          > > "vvernon_shiftmethod" <vvernon@> wrote:
                          > > > >
                          > > > > Stuart,
                          > > > >
                          > > > > I have a few thoughts on this.
                          > > > >
                          > > > > > 1. I could add a method to the domain object and for each
                          > > > > > child object from the root pass the DTO and have the object
                          > > > > > update itself:
                          > > > >
                          > > > > The only things that belong in your domain are terms from you UL. Also
                          > > DTOs are not domain objects. They are anemic objects that help bridge
                          > > physical tiers in separate processes. You could consider making your
                          > > application layer service methods receive serialized domain command objects
                          > > instead. But if you are tied to DTOs in the application layer, at a minimum
                          > > you need to translate DTOs into domain objects (see below).
                          > > > >
                          > > > > > 2. I could create a command to wrap the DTO but IMHO this
                          > > > > > removes the business logic from the domain to the command
                          > > > > > and the functionality could be implemented in the
                          > > > > > XXXService.provideXXXFunctionality method
                          > > > >
                          > > > > If you create commands, don't make them DTO wrappers. Also, commands
                          > > don't have to implement the mutation behavior on the aggregates. More often,
                          > > IMO, a command tells the aggregate what to do and with what, but doesn't do
                          > > the command.
                          > > > >
                          > > > > > 3. Visitor pattern? Same drawbacks as the command pattern
                          > > > >
                          > > > > Well, I think the behavior is better if implemented in the aggregate.
                          > > But it might depend on the level of complexity.
                          > > > >
                          > > > > All the above considered, I wonder if your application service methods
                          > > are revealing domain responsibilities. Remember that Domain Services are
                          > > meant to deal with domain behavior that doesn't fit or belong on any one
                          > > domain object (aggregate, entity, value, whatever). Rather the Domain
                          > > Service orchestrates behaviors across multiple domain objects. So as your
                          > > application service requests arrive, consider translating the DTOs into
                          > > domain objects of some kind, either commands or value objects. Then invoke a
                          > > Domain Service method, which as a receiver might be named closely to the
                          > > application service sender, passing the translated parameters (command or
                          > > value objects). That Domain Service would use Repositories to find
                          > > aggregates that overlap in the use case / user story, and invoke command
                          > > methods on those aggregates, passing the applicable parts of the parameter
                          > > domain objects (commands or value objects). That will help correctly keep
                          > > your application services thin and retain your business logic only in the
                          > > core domain model.
                          > > > >
                          > > > > Vaughn
                          > > > >
                          > > > >
                          > > > >
                          > > > > --- In domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,
                          > > "stuart_faircloth" <stuart_faircloth@> wrote:
                          > > > > >
                          > > > > > Hi,
                          > > > > >
                          > > > > > My architecture is very simple. We have an entry point (service) into
                          > > the system which receives a DTO:
                          > > > > >
                          > > > > > interface XXXService {
                          > > > > > void provideXXXFunctionality(XXXDTO dto);
                          > > > > > }
                          > > > > >
                          > > > > > These DTOs are then used to update domain objects. The DTO is complex
                          > > and can update many objects under an aggregate root. How is the updating of
                          > > the domain object best achieved?
                          > > > > >
                          > > > > > 1. I could add a method to the domain object and for each child
                          > > object from the root pass the DTO and have the object update itself:
                          > > > > >
                          > > > > > class Domain {
                          > > > > > public void updateForXXX(XXXDTO dto);
                          > > > > > }
                          > > > > >
                          > > > > > But ideally I would like to keep the DTO out of the domain.
                          > > > > >
                          > > > > > 2. I could create a command to wrap the DTO but IMHO this removes the
                          > > business logic from the domain to the command and the functionality could be
                          > > implemented in the XXXService.provideXXXFunctionality method
                          > > > > >
                          > > > > > 3. Visitor pattern? Same drawbacks as the command pattern
                          > > > > >
                          > > > >
                          > > >
                          > >
                          > >
                          > >
                          >
                          >
                          >
                          > --
                          > Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de
                          > votre attention
                          >
                        • Martin Nilsson
                          Are your handlers outside the domain like in a service layer? If you don t have domain messages isn t there a risk that your domain entities becomes anemic if
                          Message 12 of 21 , Jan 14, 2010
                          View Source
                          • 0 Attachment
                            Are your handlers outside the domain like in a service layer? If you don't have domain messages isn't there a risk that your domain entities becomes anemic if it's someone outside that sets the state and also aren't we breaking the Law of Demeter rule here?

                            public class ChangeOrderHandler : IHandler<ChangeOrderMessage>
                            {
                              public void Handle(ChangeOrderMessage message)
                              {
                                 Order order = repository.GetById(message.OrderNumber);
                                 order.DeliveryAddress.FirstName = message.DeliveryAddressFirstName;     
                                 ...     
                              }
                            }

                            On Thu, Jan 14, 2010 at 9:16 AM, Greg Young <gregoryyoung1@...> wrote:
                             

                            Generally I would avoid having the domain directly access the commands but would instead have the mapping logic likely in the command handler. there are however times when the coupling can be acceptable



                            On Thu, Jan 14, 2010 at 8:16 AM, vvernon_shiftmethod <vvernon@...> wrote:
                             

                            I was indicating that you might have some terminology in your model, such as "Change an Order", which would lead to creating the following domain command class:

                            public class ChangeOrderCommand {...} // serializable

                            Then on your Order class you have a method such as:

                            public class Order {
                            // ...
                            public void change(ChangeOrderCommand aCommand) {
                            // modify myself based on aCommand...
                            }
                            }

                            How your ChangeOrderCommand is created doesn't matter. It might get populated by UI mappings, it might come in from a web service request, or whatever.

                            If you are tied to using DTOs, then you would create a ChangeOrderCommand from your DTO attributes as you indicated below. But it would be unfortunate if you were required to use a DTO, because that's unnecessary complexity if you have domain commands.



                            Vaughn

                            --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@...> wrote:
                            >
                            > Here is a different example
                            >
                            > // domain object(s)
                            > class Order {
                            > // large number of properties
                            > }
                            >
                            > class OrderLine {
                            > Order createOrder(CreateOrderDTO dto);
                            > }
                            >
                            > // dto (complex object)
                            > class CreateOrderRequestDTO {
                            > String orderType;
                            > double qty;
                            > .....
                            > }
                            >
                            > How would you remove the DTO? I could replace it with another object (specification?) but that would have almost the same properties as the DTO.
                            >
                            > Here is another example:
                            >
                            > // dto
                            > class ModifyOrderRequestDTO {
                            > X x;
                            > Y y;
                            > }
                            >
                            > // domain object
                            > class Order {
                            > public void modify(ModifyOrderRequestDTO modification) {
                            > setX(modification.x);
                            > setY(modification.y);
                            > }
                            > }
                            >
                            > possible soln (doesn't appear to provide any benefits):
                            >
                            > class Transformer {
                            > ModifyRequest transform(ModifyRequestDTO dto) {
                            > return new ModifyRequest(dto.x, dto.y);
                            > }
                            > }
                            >
                            >
                            > class ModifyRequest {
                            > X x;
                            > Y y;
                            >
                            > void applyTo(Order order) {
                            > order.setX(x);
                            > order.setY(y);
                            > }
                            > }
                            >
                            > class Order {
                            > public void applyUpdate(ModifyRequest modification) {
                            > modification.applyTo(this);
                            > }
                            > }
                            >
                            >
                            > --- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@> wrote:
                            > >
                            > > Stuart,
                            > >
                            > > I have a few thoughts on this.
                            > >
                            > > > 1. I could add a method to the domain object and for each
                            > > > child object from the root pass the DTO and have the object
                            > > > update itself:
                            > >
                            > > The only things that belong in your domain are terms from you UL. Also DTOs are not domain objects. They are anemic objects that help bridge physical tiers in separate processes. You could consider making your application layer service methods receive serialized domain command objects instead. But if you are tied to DTOs in the application layer, at a minimum you need to translate DTOs into domain objects (see below).
                            > >
                            > > > 2. I could create a command to wrap the DTO but IMHO this
                            > > > removes the business logic from the domain to the command
                            > > > and the functionality could be implemented in the
                            > > > XXXService.provideXXXFunctionality method
                            > >
                            > > If you create commands, don't make them DTO wrappers. Also, commands don't have to implement the mutation behavior on the aggregates. More often, IMO, a command tells the aggregate what to do and with what, but doesn't do the command.
                            > >
                            > > > 3. Visitor pattern? Same drawbacks as the command pattern
                            > >
                            > > Well, I think the behavior is better if implemented in the aggregate. But it might depend on the level of complexity.
                            > >
                            > > All the above considered, I wonder if your application service methods are revealing domain responsibilities. Remember that Domain Services are meant to deal with domain behavior that doesn't fit or belong on any one domain object (aggregate, entity, value, whatever). Rather the Domain Service orchestrates behaviors across multiple domain objects. So as your application service requests arrive, consider translating the DTOs into domain objects of some kind, either commands or value objects. Then invoke a Domain Service method, which as a receiver might be named closely to the application service sender, passing the translated parameters (command or value objects). That Domain Service would use Repositories to find aggregates that overlap in the use case / user story, and invoke command methods on those aggregates, passing the applicable parts of the parameter domain objects (commands or value objects). That will help correctly keep your application services thin and retain your business logic only in the core domain model.
                            > >
                            > > Vaughn
                            > >
                            > >
                            > >
                            > > --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@> wrote:
                            > > >
                            > > > Hi,
                            > > >
                            > > > My architecture is very simple. We have an entry point (service) into the system which receives a DTO:
                            > > >
                            > > > interface XXXService {
                            > > > void provideXXXFunctionality(XXXDTO dto);
                            > > > }
                            > > >
                            > > > These DTOs are then used to update domain objects. The DTO is complex and can update many objects under an aggregate root. How is the updating of the domain object best achieved?
                            > > >
                            > > > 1. I could add a method to the domain object and for each child object from the root pass the DTO and have the object update itself:
                            > > >
                            > > > class Domain {
                            > > > public void updateForXXX(XXXDTO dto);
                            > > > }
                            > > >
                            > > > But ideally I would like to keep the DTO out of the domain.
                            > > >
                            > > > 2. I could create a command to wrap the DTO but IMHO this removes the business logic from the domain to the command and the functionality could be implemented in the XXXService.provideXXXFunctionality method
                            > > >
                            > > > 3. Visitor pattern? Same drawbacks as the command pattern
                            > > >
                            > >
                            >




                            --
                            Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de votre attention

                          • Greg Young
                            As I said there are times when the coupling can be ok. In terms of an example, its just a class very similar to an application service that receives the
                            Message 13 of 21 , Jan 14, 2010
                            View Source
                            • 0 Attachment
                              As I said there are times when the coupling can be ok.

                              In terms of an example, its just a class very similar to an application service that receives the command and maps it to the domain object..

                              As an example:

                              public class DeactivateItemCommand {
                                  public Guid ItemId;
                                  public string reason;
                              }

                              public class DeactivateItemCommandHandler : ICommandHandler<DeactivateItemCommand> {
                                  //use DI on constructor etc
                                  public void Handle(DeactivateItemCommand cmd) {
                                       item = repository.GetItemById(cmd.ItemId);
                                       item.Deactivate(cmd.reason);
                                  }
                              }

                              The main reasoning for this is packaging and dependencies, the command package is published (and versionized to clients). The commands are really just a published schema. Having the domain directly access this package is a bit weird.

                              Cheers,

                              Greg

                              On Thu, Jan 14, 2010 at 10:36 AM, vvernon_shiftmethod <vvernon@...> wrote:
                               

                              BTW, I don't consider the coupling a problem because the Commands live in the same Module with the Aggregate they are used by.

                              Also this reflects what I posted around a year ago on the topic of "Editing Domain Model." I recall that you replied somewhere along the thread and indicated that you had previously used the same pattern.

                              It's pretty late here... will check back when the sun rises.

                              Vaughn



                              --- In domaindrivendesign@yahoogroups.com, Greg Young <gregoryyoung1@...> wrote:
                              >
                              > Generally I would avoid having the domain directly access the commands but
                              > would instead have the mapping logic likely in the command handler. there
                              > are however times when the coupling can be acceptable
                              >
                              > On Thu, Jan 14, 2010 at 8:16 AM, vvernon_shiftmethod <
                              > vvernon@...> wrote:
                              >
                              > >
                              > >
                              > > I was indicating that you might have some terminology in your model, such
                              > > as "Change an Order", which would lead to creating the following domain
                              > > command class:
                              > >
                              > > public class ChangeOrderCommand {...} // serializable
                              > >
                              > > Then on your Order class you have a method such as:
                              > >
                              > > public class Order {
                              > > // ...
                              > > public void change(ChangeOrderCommand aCommand) {
                              > > // modify myself based on aCommand...
                              > > }
                              > > }
                              > >
                              > > How your ChangeOrderCommand is created doesn't matter. It might get
                              > > populated by UI mappings, it might come in from a web service request, or
                              > > whatever.
                              > >
                              > > If you are tied to using DTOs, then you would create a ChangeOrderCommand
                              > > from your DTO attributes as you indicated below. But it would be unfortunate
                              > > if you were required to use a DTO, because that's unnecessary complexity if
                              > > you have domain commands.
                              > >
                              > >
                              > > Vaughn
                              > >
                              > > --- In domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,

                              > > "stuart_faircloth" <stuart_faircloth@> wrote:
                              > > >
                              > > > Here is a different example
                              > > >
                              > > > // domain object(s)
                              > > > class Order {
                              > > > // large number of properties
                              > > > }
                              > > >
                              > > > class OrderLine {
                              > > > Order createOrder(CreateOrderDTO dto);
                              > > > }
                              > > >
                              > > > // dto (complex object)
                              > > > class CreateOrderRequestDTO {
                              > > > String orderType;
                              > > > double qty;
                              > > > .....
                              > > > }
                              > > >
                              > > > How would you remove the DTO? I could replace it with another object
                              > > (specification?) but that would have almost the same properties as the DTO.
                              > > >
                              > > > Here is another example:
                              > > >
                              > > > // dto
                              > > > class ModifyOrderRequestDTO {
                              > > > X x;
                              > > > Y y;
                              > > > }
                              > > >
                              > > > // domain object
                              > > > class Order {
                              > > > public void modify(ModifyOrderRequestDTO modification) {
                              > > > setX(modification.x);
                              > > > setY(modification.y);
                              > > > }
                              > > > }
                              > > >
                              > > > possible soln (doesn't appear to provide any benefits):
                              > > >
                              > > > class Transformer {
                              > > > ModifyRequest transform(ModifyRequestDTO dto) {
                              > > > return new ModifyRequest(dto.x, dto.y);
                              > > > }
                              > > > }
                              > > >
                              > > >
                              > > > class ModifyRequest {
                              > > > X x;
                              > > > Y y;
                              > > >
                              > > > void applyTo(Order order) {
                              > > > order.setX(x);
                              > > > order.setY(y);
                              > > > }
                              > > > }
                              > > >
                              > > > class Order {
                              > > > public void applyUpdate(ModifyRequest modification) {
                              > > > modification.applyTo(this);
                              > > > }
                              > > > }
                              > > >
                              > > >
                              > > > --- In domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,

                              > > "vvernon_shiftmethod" <vvernon@> wrote:
                              > > > >
                              > > > > Stuart,
                              > > > >
                              > > > > I have a few thoughts on this.
                              > > > >
                              > > > > > 1. I could add a method to the domain object and for each
                              > > > > > child object from the root pass the DTO and have the object
                              > > > > > update itself:
                              > > > >
                              > > > > The only things that belong in your domain are terms from you UL. Also
                              > > DTOs are not domain objects. They are anemic objects that help bridge
                              > > physical tiers in separate processes. You could consider making your
                              > > application layer service methods receive serialized domain command objects
                              > > instead. But if you are tied to DTOs in the application layer, at a minimum
                              > > you need to translate DTOs into domain objects (see below).
                              > > > >
                              > > > > > 2. I could create a command to wrap the DTO but IMHO this
                              > > > > > removes the business logic from the domain to the command
                              > > > > > and the functionality could be implemented in the
                              > > > > > XXXService.provideXXXFunctionality method
                              > > > >
                              > > > > If you create commands, don't make them DTO wrappers. Also, commands
                              > > don't have to implement the mutation behavior on the aggregates. More often,
                              > > IMO, a command tells the aggregate what to do and with what, but doesn't do
                              > > the command.
                              > > > >
                              > > > > > 3. Visitor pattern? Same drawbacks as the command pattern
                              > > > >
                              > > > > Well, I think the behavior is better if implemented in the aggregate.
                              > > But it might depend on the level of complexity.
                              > > > >
                              > > > > All the above considered, I wonder if your application service methods
                              > > are revealing domain responsibilities. Remember that Domain Services are
                              > > meant to deal with domain behavior that doesn't fit or belong on any one
                              > > domain object (aggregate, entity, value, whatever). Rather the Domain
                              > > Service orchestrates behaviors across multiple domain objects. So as your
                              > > application service requests arrive, consider translating the DTOs into
                              > > domain objects of some kind, either commands or value objects. Then invoke a
                              > > Domain Service method, which as a receiver might be named closely to the
                              > > application service sender, passing the translated parameters (command or
                              > > value objects). That Domain Service would use Repositories to find
                              > > aggregates that overlap in the use case / user story, and invoke command
                              > > methods on those aggregates, passing the applicable parts of the parameter
                              > > domain objects (commands or value objects). That will help correctly keep
                              > > your application services thin and retain your business logic only in the
                              > > core domain model.
                              > > > >
                              > > > > Vaughn
                              > > > >
                              > > > >
                              > > > >
                              > > > > --- In domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,

                              > > "stuart_faircloth" <stuart_faircloth@> wrote:
                              > > > > >
                              > > > > > Hi,
                              > > > > >
                              > > > > > My architecture is very simple. We have an entry point (service) into
                              > > the system which receives a DTO:
                              > > > > >
                              > > > > > interface XXXService {
                              > > > > > void provideXXXFunctionality(XXXDTO dto);
                              > > > > > }
                              > > > > >
                              > > > > > These DTOs are then used to update domain objects. The DTO is complex
                              > > and can update many objects under an aggregate root. How is the updating of
                              > > the domain object best achieved?
                              > > > > >
                              > > > > > 1. I could add a method to the domain object and for each child
                              > > object from the root pass the DTO and have the object update itself:
                              > > > > >
                              > > > > > class Domain {
                              > > > > > public void updateForXXX(XXXDTO dto);
                              > > > > > }
                              > > > > >
                              > > > > > But ideally I would like to keep the DTO out of the domain.
                              > > > > >
                              > > > > > 2. I could create a command to wrap the DTO but IMHO this removes the
                              > > business logic from the domain to the command and the functionality could be
                              > > implemented in the XXXService.provideXXXFunctionality method
                              > > > > >
                              > > > > > 3. Visitor pattern? Same drawbacks as the command pattern
                              > > > > >
                              > > > >
                              > > >
                              > >
                              > >
                              > >
                              >
                              >
                              >
                              > --
                              > Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de
                              > votre attention
                              >




                              --
                              Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de votre attention
                            • Greg Young
                              The problem here is your domain object and your UL You have modeled CRUD opposed to behavior. Cheers, Greg ... -- Les erreurs de grammaire et de syntaxe ont
                              Message 14 of 21 , Jan 14, 2010
                              View Source
                              • 0 Attachment
                                The problem here is your domain object and your UL

                                You have modeled CRUD opposed to behavior.

                                Cheers,

                                Greg

                                On Thu, Jan 14, 2010 at 10:43 AM, Martin Nilsson <mffmartin@...> wrote:
                                 

                                Are your handlers outside the domain like in a service layer? If you don't have domain messages isn't there a risk that your domain entities becomes anemic if it's someone outside that sets the state and also aren't we breaking the Law of Demeter rule here?

                                public class ChangeOrderHandler : IHandler<ChangeOrderMessage>
                                {
                                  public void Handle(ChangeOrderMessage message)
                                  {
                                     Order order = repository.GetById(message.OrderNumber);
                                     order.DeliveryAddress.FirstName = message.DeliveryAddressFirstName;     
                                     ...     
                                  }
                                }

                                On Thu, Jan 14, 2010 at 9:16 AM, Greg Young <gregoryyoung1@...> wrote:
                                 

                                Generally I would avoid having the domain directly access the commands but would instead have the mapping logic likely in the command handler. there are however times when the coupling can be acceptable



                                On Thu, Jan 14, 2010 at 8:16 AM, vvernon_shiftmethod <vvernon@...> wrote:
                                 

                                I was indicating that you might have some terminology in your model, such as "Change an Order", which would lead to creating the following domain command class:

                                public class ChangeOrderCommand {...} // serializable

                                Then on your Order class you have a method such as:

                                public class Order {
                                // ...
                                public void change(ChangeOrderCommand aCommand) {
                                // modify myself based on aCommand...
                                }
                                }

                                How your ChangeOrderCommand is created doesn't matter. It might get populated by UI mappings, it might come in from a web service request, or whatever.

                                If you are tied to using DTOs, then you would create a ChangeOrderCommand from your DTO attributes as you indicated below. But it would be unfortunate if you were required to use a DTO, because that's unnecessary complexity if you have domain commands.



                                Vaughn

                                --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@...> wrote:
                                >
                                > Here is a different example
                                >
                                > // domain object(s)
                                > class Order {
                                > // large number of properties
                                > }
                                >
                                > class OrderLine {
                                > Order createOrder(CreateOrderDTO dto);
                                > }
                                >
                                > // dto (complex object)
                                > class CreateOrderRequestDTO {
                                > String orderType;
                                > double qty;
                                > .....
                                > }
                                >
                                > How would you remove the DTO? I could replace it with another object (specification?) but that would have almost the same properties as the DTO.
                                >
                                > Here is another example:
                                >
                                > // dto
                                > class ModifyOrderRequestDTO {
                                > X x;
                                > Y y;
                                > }
                                >
                                > // domain object
                                > class Order {
                                > public void modify(ModifyOrderRequestDTO modification) {
                                > setX(modification.x);
                                > setY(modification.y);
                                > }
                                > }
                                >
                                > possible soln (doesn't appear to provide any benefits):
                                >
                                > class Transformer {
                                > ModifyRequest transform(ModifyRequestDTO dto) {
                                > return new ModifyRequest(dto.x, dto.y);
                                > }
                                > }
                                >
                                >
                                > class ModifyRequest {
                                > X x;
                                > Y y;
                                >
                                > void applyTo(Order order) {
                                > order.setX(x);
                                > order.setY(y);
                                > }
                                > }
                                >
                                > class Order {
                                > public void applyUpdate(ModifyRequest modification) {
                                > modification.applyTo(this);
                                > }
                                > }
                                >
                                >
                                > --- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@> wrote:
                                > >
                                > > Stuart,
                                > >
                                > > I have a few thoughts on this.
                                > >
                                > > > 1. I could add a method to the domain object and for each
                                > > > child object from the root pass the DTO and have the object
                                > > > update itself:
                                > >
                                > > The only things that belong in your domain are terms from you UL. Also DTOs are not domain objects. They are anemic objects that help bridge physical tiers in separate processes. You could consider making your application layer service methods receive serialized domain command objects instead. But if you are tied to DTOs in the application layer, at a minimum you need to translate DTOs into domain objects (see below).
                                > >
                                > > > 2. I could create a command to wrap the DTO but IMHO this
                                > > > removes the business logic from the domain to the command
                                > > > and the functionality could be implemented in the
                                > > > XXXService.provideXXXFunctionality method
                                > >
                                > > If you create commands, don't make them DTO wrappers. Also, commands don't have to implement the mutation behavior on the aggregates. More often, IMO, a command tells the aggregate what to do and with what, but doesn't do the command.
                                > >
                                > > > 3. Visitor pattern? Same drawbacks as the command pattern
                                > >
                                > > Well, I think the behavior is better if implemented in the aggregate. But it might depend on the level of complexity.
                                > >
                                > > All the above considered, I wonder if your application service methods are revealing domain responsibilities. Remember that Domain Services are meant to deal with domain behavior that doesn't fit or belong on any one domain object (aggregate, entity, value, whatever). Rather the Domain Service orchestrates behaviors across multiple domain objects. So as your application service requests arrive, consider translating the DTOs into domain objects of some kind, either commands or value objects. Then invoke a Domain Service method, which as a receiver might be named closely to the application service sender, passing the translated parameters (command or value objects). That Domain Service would use Repositories to find aggregates that overlap in the use case / user story, and invoke command methods on those aggregates, passing the applicable parts of the parameter domain objects (commands or value objects). That will help correctly keep your application services thin and retain your business logic only in the core domain model.
                                > >
                                > > Vaughn
                                > >
                                > >
                                > >
                                > > --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@> wrote:
                                > > >
                                > > > Hi,
                                > > >
                                > > > My architecture is very simple. We have an entry point (service) into the system which receives a DTO:
                                > > >
                                > > > interface XXXService {
                                > > > void provideXXXFunctionality(XXXDTO dto);
                                > > > }
                                > > >
                                > > > These DTOs are then used to update domain objects. The DTO is complex and can update many objects under an aggregate root. How is the updating of the domain object best achieved?
                                > > >
                                > > > 1. I could add a method to the domain object and for each child object from the root pass the DTO and have the object update itself:
                                > > >
                                > > > class Domain {
                                > > > public void updateForXXX(XXXDTO dto);
                                > > > }
                                > > >
                                > > > But ideally I would like to keep the DTO out of the domain.
                                > > >
                                > > > 2. I could create a command to wrap the DTO but IMHO this removes the business logic from the domain to the command and the functionality could be implemented in the XXXService.provideXXXFunctionality method
                                > > >
                                > > > 3. Visitor pattern? Same drawbacks as the command pattern
                                > > >
                                > >
                                >




                                --
                                Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de votre attention




                                --
                                Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de votre attention
                              • Martin Nilsson
                                Generally I would avoid having the domain directly access the commands but would instead have the mapping logic likely in the command handler. there are
                                Message 15 of 21 , Jan 14, 2010
                                View Source
                                • 0 Attachment
                                  "Generally I would avoid having the domain directly access the commands but would instead have the mapping logic likely in the command handler. there are however times when the coupling can be acceptable"

                                  That's why I got a little bit confused because I interpreted it as the handler was setting the state of the domain object. But I do the same as you, or think I do.., by calling behavior on the domain. But I might be wrong but I call the parameters (var "message" below) domain messages.

                                  public class DeactivateItemCommand {
                                    public Guid ItemId;
                                    public string reason;
                                    public string userId;
                                  }

                                  public class DeactivateItemCommandHandler : ICommandHandler<DeactivateItemCommand> {
                                    //use DI on constructor etc
                                    public void Handle(DeactivateItemCommand cmd) {
                                      item = repository.GetItemById(cmd.ItemId);
                                     
                                      DeactivateItemMessage message = new DeactivateItemMessage(cmd.Reason, cmd.UserId);
                                      item.Deactivate(message);
                                    }
                                  }

                                  Thanks for your input.

                                  On Thu, Jan 14, 2010 at 9:47 AM, Greg Young <gregoryyoung1@...> wrote:
                                   

                                  The problem here is your domain object and your UL

                                  You have modeled CRUD opposed to behavior.

                                  Cheers,

                                  Greg

                                  On Thu, Jan 14, 2010 at 10:43 AM, Martin Nilsson <mffmartin@...> wrote:
                                   

                                  Are your handlers outside the domain like in a service layer? If you don't have domain messages isn't there a risk that your domain entities becomes anemic if it's someone outside that sets the state and also aren't we breaking the Law of Demeter rule here?

                                  public class ChangeOrderHandler : IHandler<ChangeOrderMessage>
                                  {
                                    public void Handle(ChangeOrderMessage message)
                                    {
                                       Order order = repository.GetById(message.OrderNumber);
                                       order.DeliveryAddress.FirstName = message.DeliveryAddressFirstName;     
                                       ...     
                                    }
                                  }

                                  On Thu, Jan 14, 2010 at 9:16 AM, Greg Young <gregoryyoung1@...> wrote:
                                   

                                  Generally I would avoid having the domain directly access the commands but would instead have the mapping logic likely in the command handler. there are however times when the coupling can be acceptable



                                  On Thu, Jan 14, 2010 at 8:16 AM, vvernon_shiftmethod <vvernon@...> wrote:
                                   

                                  I was indicating that you might have some terminology in your model, such as "Change an Order", which would lead to creating the following domain command class:

                                  public class ChangeOrderCommand {...} // serializable

                                  Then on your Order class you have a method such as:

                                  public class Order {
                                  // ...
                                  public void change(ChangeOrderCommand aCommand) {
                                  // modify myself based on aCommand...
                                  }
                                  }

                                  How your ChangeOrderCommand is created doesn't matter. It might get populated by UI mappings, it might come in from a web service request, or whatever.

                                  If you are tied to using DTOs, then you would create a ChangeOrderCommand from your DTO attributes as you indicated below. But it would be unfortunate if you were required to use a DTO, because that's unnecessary complexity if you have domain commands.



                                  Vaughn

                                  --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@...> wrote:
                                  >
                                  > Here is a different example
                                  >
                                  > // domain object(s)
                                  > class Order {
                                  > // large number of properties
                                  > }
                                  >
                                  > class OrderLine {
                                  > Order createOrder(CreateOrderDTO dto);
                                  > }
                                  >
                                  > // dto (complex object)
                                  > class CreateOrderRequestDTO {
                                  > String orderType;
                                  > double qty;
                                  > .....
                                  > }
                                  >
                                  > How would you remove the DTO? I could replace it with another object (specification?) but that would have almost the same properties as the DTO.
                                  >
                                  > Here is another example:
                                  >
                                  > // dto
                                  > class ModifyOrderRequestDTO {
                                  > X x;
                                  > Y y;
                                  > }
                                  >
                                  > // domain object
                                  > class Order {
                                  > public void modify(ModifyOrderRequestDTO modification) {
                                  > setX(modification.x);
                                  > setY(modification.y);
                                  > }
                                  > }
                                  >
                                  > possible soln (doesn't appear to provide any benefits):
                                  >
                                  > class Transformer {
                                  > ModifyRequest transform(ModifyRequestDTO dto) {
                                  > return new ModifyRequest(dto.x, dto.y);
                                  > }
                                  > }
                                  >
                                  >
                                  > class ModifyRequest {
                                  > X x;
                                  > Y y;
                                  >
                                  > void applyTo(Order order) {
                                  > order.setX(x);
                                  > order.setY(y);
                                  > }
                                  > }
                                  >
                                  > class Order {
                                  > public void applyUpdate(ModifyRequest modification) {
                                  > modification.applyTo(this);
                                  > }
                                  > }
                                  >
                                  >
                                  > --- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@> wrote:
                                  > >
                                  > > Stuart,
                                  > >
                                  > > I have a few thoughts on this.
                                  > >
                                  > > > 1. I could add a method to the domain object and for each
                                  > > > child object from the root pass the DTO and have the object
                                  > > > update itself:
                                  > >
                                  > > The only things that belong in your domain are terms from you UL. Also DTOs are not domain objects. They are anemic objects that help bridge physical tiers in separate processes. You could consider making your application layer service methods receive serialized domain command objects instead. But if you are tied to DTOs in the application layer, at a minimum you need to translate DTOs into domain objects (see below).
                                  > >
                                  > > > 2. I could create a command to wrap the DTO but IMHO this
                                  > > > removes the business logic from the domain to the command
                                  > > > and the functionality could be implemented in the
                                  > > > XXXService.provideXXXFunctionality method
                                  > >
                                  > > If you create commands, don't make them DTO wrappers. Also, commands don't have to implement the mutation behavior on the aggregates. More often, IMO, a command tells the aggregate what to do and with what, but doesn't do the command.
                                  > >
                                  > > > 3. Visitor pattern? Same drawbacks as the command pattern
                                  > >
                                  > > Well, I think the behavior is better if implemented in the aggregate. But it might depend on the level of complexity.
                                  > >
                                  > > All the above considered, I wonder if your application service methods are revealing domain responsibilities. Remember that Domain Services are meant to deal with domain behavior that doesn't fit or belong on any one domain object (aggregate, entity, value, whatever). Rather the Domain Service orchestrates behaviors across multiple domain objects. So as your application service requests arrive, consider translating the DTOs into domain objects of some kind, either commands or value objects. Then invoke a Domain Service method, which as a receiver might be named closely to the application service sender, passing the translated parameters (command or value objects). That Domain Service would use Repositories to find aggregates that overlap in the use case / user story, and invoke command methods on those aggregates, passing the applicable parts of the parameter domain objects (commands or value objects). That will help correctly keep your application services thin and retain your business logic only in the core domain model.
                                  > >
                                  > > Vaughn
                                  > >
                                  > >
                                  > >
                                  > > --- In domaindrivendesign@yahoogroups.com, "stuart_faircloth" <stuart_faircloth@> wrote:
                                  > > >
                                  > > > Hi,
                                  > > >
                                  > > > My architecture is very simple. We have an entry point (service) into the system which receives a DTO:
                                  > > >
                                  > > > interface XXXService {
                                  > > > void provideXXXFunctionality(XXXDTO dto);
                                  > > > }
                                  > > >
                                  > > > These DTOs are then used to update domain objects. The DTO is complex and can update many objects under an aggregate root. How is the updating of the domain object best achieved?
                                  > > >
                                  > > > 1. I could add a method to the domain object and for each child object from the root pass the DTO and have the object update itself:
                                  > > >
                                  > > > class Domain {
                                  > > > public void updateForXXX(XXXDTO dto);
                                  > > > }
                                  > > >
                                  > > > But ideally I would like to keep the DTO out of the domain.
                                  > > >
                                  > > > 2. I could create a command to wrap the DTO but IMHO this removes the business logic from the domain to the command and the functionality could be implemented in the XXXService.provideXXXFunctionality method
                                  > > >
                                  > > > 3. Visitor pattern? Same drawbacks as the command pattern
                                  > > >
                                  > >
                                  >




                                  --
                                  Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de votre attention




                                  --
                                  Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de votre attention

                                • Nuno Lopes
                                  Hi Stuart, ... Instead of the above rename the stuff to: interface IXXXCmdHandler { void Handle(IXXXCmd cmd); } So now what kind of object should implement
                                  Message 16 of 21 , Jan 14, 2010
                                  View Source
                                  • 0 Attachment
                                    Hi Stuart,

                                    Short answer:

                                    interface XXXService {
                                    void provideXXXFunctiona lity(XXXDTO dto);
                                    }

                                    Instead of the above rename the stuff to:

                                    interface IXXXCmdHandler {
                                       void Handle(IXXXCmd cmd);
                                    }

                                    So now what kind of object should implement such interface? Some people have the domain object implementing it, others have a Facade around a Bounded Context.

                                    class XFacade : IXXXCmdHandler, ......
                                    {
                                         void Handler(IXXXCmd cmd)
                                         {
                                             /// transaction start
                                             DomainObjectX x = RepositoryX.Get(cmd.DomainObjectXID);
                                             x.Method(cmd.P1, ...., cmd.Pn)
                                             /// transaction end;

                                            // send an email or whatever.
                                         }
                                    }

                                    ....

                                    IXXXCmdHandler handler = IoC.Get<IXXXCmdHandler>();
                                    try {
                                        handler.Handle(cmd);
                                    }
                                    catch (...) ...

                                    IMHO commands belong outside the Bounded Context. Does this make sense?

                                    Cheers,

                                    Nuno
                                  • Nuno Lopes
                                    ... class Facade : IXXXCmdHandler, IYYYCmdHandler, ..., INNNCmdHandler, ICmdHandler { void Handle(IXXXCmd cmd) {....}; void Handle(IYYYCmd cmd) {....}; ......
                                    Message 17 of 21 , Jan 14, 2010
                                    View Source
                                    • 0 Attachment
                                      A friend of mine asked me if what I proposed was really a facade:

                                      > class XFacade : IXXXCmdHandler, ......
                                      > {
                                      > void Handler(IXXXCmd cmd)
                                      > {
                                      > /// transaction start
                                      > DomainObjectX x = RepositoryX.Get(cmd.DomainObjectXID);
                                      > x.Method(cmd.P1, ...., cmd.Pn)
                                      > /// transaction end;
                                      >
                                      > // send an email or whatever.
                                      > }
                                      > }


                                      class Facade : IXXXCmdHandler, IYYYCmdHandler, ..., INNNCmdHandler, ICmdHandler
                                      {
                                      void Handle(IXXXCmd cmd) {....};
                                      void Handle(IYYYCmd cmd) {....};
                                      ......
                                      void Handle(INNNCmd cmd) {....};
                                      }

                                      Overloading does the rest. No need for special dispatchers or DI in its simplest form.

                                      So it is facade. In this case, the facade is built in order to make the domain model work easily with commands while keeping these artifacts out.

                                      Cheers,

                                      Nuno
                                    • Greg Young
                                      This can be workable but it can also introduce a lot of dependencies to a singla class (which is why many use DI with class per role). It also creates a class
                                      Message 18 of 21 , Jan 14, 2010
                                      View Source
                                      • 0 Attachment
                                        This can be workable but it can also introduce a lot of dependencies to a singla class (which is why many use DI with class per role). It also creates a class that is fairly low cohesion but there are definitely reasons why this can be desirable (especially with relatively few commands).

                                        Cheers,

                                        Greg

                                        On Thu, Jan 14, 2010 at 7:05 PM, Nuno Lopes <nbplopes@...> wrote:
                                         

                                        A friend of mine asked me if what I proposed was really a facade:



                                        > class XFacade : IXXXCmdHandler, ......
                                        > {
                                        > void Handler(IXXXCmd cmd)
                                        > {
                                        > /// transaction start
                                        > DomainObjectX x = RepositoryX.Get(cmd.DomainObjectXID);
                                        > x.Method(cmd.P1, ...., cmd.Pn)
                                        > /// transaction end;
                                        >
                                        > // send an email or whatever.
                                        > }
                                        > }

                                        class Facade : IXXXCmdHandler, IYYYCmdHandler, ..., INNNCmdHandler, ICmdHandler
                                        {
                                        void Handle(IXXXCmd cmd) {....};
                                        void Handle(IYYYCmd cmd) {....};
                                        ......
                                        void Handle(INNNCmd cmd) {....};
                                        }

                                        Overloading does the rest. No need for special dispatchers or DI in its simplest form.

                                        So it is facade. In this case, the facade is built in order to make the domain model work easily with commands while keeping these artifacts out.

                                        Cheers,

                                        Nuno



                                        --
                                        Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de votre attention
                                      • Greg Young
                                        Also is it really a facade if you use role interfaces? wouldnt a facade specify a single interface that encompassed the role interfaces it met? eg public
                                        Message 19 of 21 , Jan 14, 2010
                                        View Source
                                        • 0 Attachment
                                          Also is it really a facade if you use role interfaces? wouldnt a facade specify a single interface that encompassed the role interfaces it met? eg

                                          public interface iwhateverfacade : Isomthing, Isomethingelse, etc {}

                                          public class whateverfacade : iwhateverfacade {}

                                          Cheers,

                                          Greg

                                          On Thu, Jan 14, 2010 at 7:05 PM, Nuno Lopes <nbplopes@...> wrote:
                                           

                                          A friend of mine asked me if what I proposed was really a facade:



                                          > class XFacade : IXXXCmdHandler, ......
                                          > {
                                          > void Handler(IXXXCmd cmd)
                                          > {
                                          > /// transaction start
                                          > DomainObjectX x = RepositoryX.Get(cmd.DomainObjectXID);
                                          > x.Method(cmd.P1, ...., cmd.Pn)
                                          > /// transaction end;
                                          >
                                          > // send an email or whatever.
                                          > }
                                          > }

                                          class Facade : IXXXCmdHandler, IYYYCmdHandler, ..., INNNCmdHandler, ICmdHandler
                                          {
                                          void Handle(IXXXCmd cmd) {....};
                                          void Handle(IYYYCmd cmd) {....};
                                          ......
                                          void Handle(INNNCmd cmd) {....};
                                          }

                                          Overloading does the rest. No need for special dispatchers or DI in its simplest form.

                                          So it is facade. In this case, the facade is built in order to make the domain model work easily with commands while keeping these artifacts out.

                                          Cheers,

                                          Nuno



                                          --
                                          Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de votre attention
                                        • stuart_faircloth
                                          You can implement this differently in a language that supports generics better than Java does: public class Facade : IMessageHandler ,
                                          Message 20 of 21 , Jan 14, 2010
                                          View Source
                                          • 0 Attachment
                                            You can implement this differently in a language that supports generics better than Java does:

                                            public class Facade : IMessageHandler<Message1>, IMessageHandler<Message2> {
                                            public void handleMessage(Message1 msg);
                                            public void handleMessage(Message2 msg);
                                            }

                                            --- In domaindrivendesign@yahoogroups.com, Greg Young <gregoryyoung1@...> wrote:
                                            >
                                            > This can be workable but it can also introduce a lot of dependencies to a
                                            > singla class (which is why many use DI with class per role). It also creates
                                            > a class that is fairly low cohesion but there are definitely reasons why
                                            > this can be desirable (especially with relatively few commands).
                                            >
                                            > Cheers,
                                            >
                                            > Greg
                                            >
                                            > On Thu, Jan 14, 2010 at 7:05 PM, Nuno Lopes <nbplopes@...> wrote:
                                            >
                                            > >
                                            > >
                                            > > A friend of mine asked me if what I proposed was really a facade:
                                            > >
                                            > >
                                            > > > class XFacade : IXXXCmdHandler, ......
                                            > > > {
                                            > > > void Handler(IXXXCmd cmd)
                                            > > > {
                                            > > > /// transaction start
                                            > > > DomainObjectX x = RepositoryX.Get(cmd.DomainObjectXID);
                                            > > > x.Method(cmd.P1, ...., cmd.Pn)
                                            > > > /// transaction end;
                                            > > >
                                            > > > // send an email or whatever.
                                            > > > }
                                            > > > }
                                            > >
                                            > > class Facade : IXXXCmdHandler, IYYYCmdHandler, ..., INNNCmdHandler,
                                            > > ICmdHandler
                                            > > {
                                            > > void Handle(IXXXCmd cmd) {....};
                                            > > void Handle(IYYYCmd cmd) {....};
                                            > > ......
                                            > > void Handle(INNNCmd cmd) {....};
                                            > > }
                                            > >
                                            > > Overloading does the rest. No need for special dispatchers or DI in its
                                            > > simplest form.
                                            > >
                                            > > So it is facade. In this case, the facade is built in order to make the
                                            > > domain model work easily with commands while keeping these artifacts out.
                                            > >
                                            > > Cheers,
                                            > >
                                            > > Nuno
                                            > >
                                            > >
                                            >
                                            >
                                            >
                                            > --
                                            > Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de
                                            > votre attention
                                            >
                                          • Nuno Lopes
                                            Hi, ... I think you could have several classes (one per use case scenario?). It depends how complex is the BC and the application. As for cohesion, yes the
                                            Message 21 of 21 , Jan 14, 2010
                                            View Source
                                            • 0 Attachment

                                              Hi,

                                              This can be workable but it can also introduce a lot of dependencies to a singla class (which is why many use DI with class per role). It also creates a class that is fairly low cohesion but there are definitely reasons why this can be desirable (especially with relatively few commands).

                                              I think you could have several classes (one per use case scenario?). It depends how complex is the BC and the application. As for cohesion, yes the class is not cohesive it simplifies coding in simple systems. The use of DI can still be used.

                                              Also is it really a facade if you use role interfaces? 

                                              The point of the Facade pattern is no so much the use of interfaces. It is simply a simplified interface to a larger body of code. I think this fits the bill as it frees the client from understanding the innards of domain objects, transaction, logging and most probably other workflow oriented tasks such as sending an email upon success etc etc.

                                              I agree with you nevertheless that in complex situation a simple facade may not fit the bill.

                                              Cheers,

                                              Nuno

                                            Your message has been successfully submitted and would be delivered to recipients shortly.