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

Re: [XP] text versions of story cards -> writing unit tests

Expand Messages
  • D. André Dhondt
    ... whiteboard for OO design, how then do we not try to slice/dice the design amongst DDD layers? Most the time you won t be working at such a high level...
    Message 1 of 36 , Apr 6 12:04 AM
    • 0 Attachment
      >So if we define the domain at a conceptual level, then we go to the
      whiteboard for OO design, how then do we not >try to slice/dice the design
      amongst DDD layers?

      Most the time you won't be working at such a high level... you'll add one
      command to the domain-level syntax and jump into red-green-refactor, which
      may need some whiteboard design or may just be small enough not to need it.
      Sometimes you'll be deep in the code and realize something needs visibility
      much higher, so you'll refactor your way up to domain-level visibility...
      this becomes emergent design--some things appear in the domain that you
      hadn't forseen.


      On Sun, Apr 5, 2009 at 12:39 AM, Justin Daubenmire <jdaubenm@...>wrote:

      > ----- Original Message -----
      > From: Steven Gordon
      >
      > Committing to the layers before starting implementation is waterfall.
      > Hide the predetermined layers in an envelope, implement the stories
      > using TDD, and then after several iterations, see if TDD (with
      > refactoring!) has lead to the same layers or not.
      >
      > I keep trying to take my swim trunks off and crawl out from under the
      > waterfall but keep slipping in! lol.
      >
      > btw what do you mean by "envelope"?
      >
      > So if we define the domain at a conceptual level, then we go to the
      > whiteboard for OO design, how then do we not try to slice/dice the design
      > amongst DDD layers?
      >
      > For example, we know conceptually in the domain that a customer is an
      > entity that has a value object called credit card.
      >
      > We then step up to the white board and start to OO model the customer
      > object and a credit card object. At this point, how would you handle working
      > through an OO design staying ignorant of DDD layers?
      >
      > Thanks for any pointers!
      >
      > Regards,
      > Justin
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >



      --
      D. André Dhondt
      mobile: 001 33 671 034 984


      [Non-text portions of this message have been removed]
    • D. André Dhondt
      ... whiteboard for OO design, how then do we not try to slice/dice the design amongst DDD layers? Most the time you won t be working at such a high level...
      Message 36 of 36 , Apr 6 12:04 AM
      • 0 Attachment
        >So if we define the domain at a conceptual level, then we go to the
        whiteboard for OO design, how then do we not >try to slice/dice the design
        amongst DDD layers?

        Most the time you won't be working at such a high level... you'll add one
        command to the domain-level syntax and jump into red-green-refactor, which
        may need some whiteboard design or may just be small enough not to need it.
        Sometimes you'll be deep in the code and realize something needs visibility
        much higher, so you'll refactor your way up to domain-level visibility...
        this becomes emergent design--some things appear in the domain that you
        hadn't forseen.


        On Sun, Apr 5, 2009 at 12:39 AM, Justin Daubenmire <jdaubenm@...>wrote:

        > ----- Original Message -----
        > From: Steven Gordon
        >
        > Committing to the layers before starting implementation is waterfall.
        > Hide the predetermined layers in an envelope, implement the stories
        > using TDD, and then after several iterations, see if TDD (with
        > refactoring!) has lead to the same layers or not.
        >
        > I keep trying to take my swim trunks off and crawl out from under the
        > waterfall but keep slipping in! lol.
        >
        > btw what do you mean by "envelope"?
        >
        > So if we define the domain at a conceptual level, then we go to the
        > whiteboard for OO design, how then do we not try to slice/dice the design
        > amongst DDD layers?
        >
        > For example, we know conceptually in the domain that a customer is an
        > entity that has a value object called credit card.
        >
        > We then step up to the white board and start to OO model the customer
        > object and a credit card object. At this point, how would you handle working
        > through an OO design staying ignorant of DDD layers?
        >
        > Thanks for any pointers!
        >
        > Regards,
        > Justin
        >
        > [Non-text portions of this message have been removed]
        >
        >
        >



        --
        D. André Dhondt
        mobile: 001 33 671 034 984


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.