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

RE: [domaindrivendesign] Re: Domain Driven Design & Business Objects

Expand Messages
  • Randy Stafford
    Hi Casey and All, I agree it s important to share an understanding of the meaning of terms - as prime examples, see
    Message 1 of 18 , Nov 30, 2006
    View Source
    • 0 Attachment

      Hi Casey and All,

       

      I agree it’s important to share an understanding of the meaning of terms – as prime examples, see http://c2.com/cgi/wiki?WhatsaControllerAnyway and http://c2.com/cgi/wiki?ModelModelViewController.

       

      For that reason, the etymology of our “terms of art” is important.  Here are a couple of publications that demonstrate that the term “domain object” was in use in the Smalltalk community since at least the late 1980s:

       

       

      The term “entity” was clearly in use in database circles since at least 1976, when Peter Chen published his famous paper.  There was also the profound 1978 book Data and Reality by William Kent, which used “entity” and remarkably foreshadowed DDD at a time when “objects” were the province of researchers and simulationists, and nowhere near the mainstream of the profession.

       

      One of the beauties of Eric’s book is that he has brought classification to domain objects - experience with DDD over the decades has shown that there want to be different “kinds” of domain object, and Eric has nailed a useful classification.  I find his choice of “entity” (to differentiate from “value”) a wise leverage of the meaning from the database tradition.

       

      Now, on the subject of what came before what, in the late 1980s when Smalltalkers were pioneering the future of enterprise application architecture, Microsoft was still maintaining DOS and just bringing Windows 3.0 to market.  It would be another decade before they and Sun would begin to confuse terminology and rediscover concepts that were already in accepted use in that influential pioneering community.  You can get other parts of the story from Dealers of Lightning or Pirates of Silicon Valley, if you’re interested.

       

      As you say, in the end, it is the design concepts that are important, but so are semantics and etymology, if we are to have clear conversations about the design concepts.

       

      Best Regards,

      Randy

       


      From: domaindrivendesign@yahoogroups.com [mailto: domaindrivendesign@yahoogroups.com ] On Behalf Of Casey Manus
      Sent: Thursday, November 30, 2006 7:35 AM
      To: domaindrivendesign@yahoogroups.com
      Subject: [domaindrivendesign] Re: Domain Driven Design & Business Objects

       

      I agree totally, we are struggling with language, not design. I
      guess I am unabled to let go of the definition(s) of Entity classes
      that were around way before Erics DDD was published. Domain object
      also had meaning.

      It reminds me of when I started learning about TDD, "Unit Test"
      already had an existing definition to me, and that meaning wasn't
      nearly as precise as it is now. At one time, we referred to any
      testing done by the developer as "unit testing".

      These are important discussions to have, as developers have to have a
      shared vocabulary in order to be a true group of professionals.

      I actually feel as though I understand the terminology Eric was
      suggesting better after talking it out with you guys.

      Thanks!

      --- In domaindrivendesign@ yahoogroups. com, "Donnchadh Ó Donnabháin"
      <donnchadh@. ..> wrote:

      >
      > On 11/29/06, Casey Manus <caseymanus@ ...> wrote:
      > > Does an address record or phone record deserve its own domain?
      No,
      > > but there could very well be a demographics domain object that
      these
      > > entities are members of. I can't ever agree that all entities
      are
      > > domain objects, although they may be members of a domain.
      >
      > By definition an object which is a member of a domain is a Domain
      > Object in the language of DDD. A Domain Object is not a
      > reprresentation of an entire domain as you seem to imply above. In
      the
      > above example an address or phone number object _are_ part of the
      > domain, probably _not_ the _core_ domain and they may be modelled as
      > Value Objects.
      >
      > A lot of this debate seems to depend on the terminonlogy used and my
      > comments assume the definitions given in Eric's book.
      >
      > Donnchadh
      >

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