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

Domain Classes or Interfaces

Expand Messages
  • ghosh.debasish
    Hi - Here is a practical dilemma that I face when doing DDD. In my domain model, I should have intention-revealing-interfaces - right ? This is what DDD
    Message 1 of 37 , Oct 25, 2006
      Hi -

      Here is a practical dilemma that I face when doing DDD. In my domain
      model, I should have intention-revealing-interfaces - right ? This is
      what DDD suggests. I assume that the term "interfaces" is not to be
      taken literally as an *interface* in Java. It can be an interface or
      an abstract class. Now, we all know that interfaces allow users to
      provide multiple implementations and are also used to implement
      multiple inheritance.

      While doing domain modeling in Java, should I have Java interfaces for
      the domain abstractions ? My personal view is that unless there is a
      strong enough reason (like necessity to implement multiple
      inheritance), we should use abstract classes as the contract. The
      reason for this, I feel is that interfaces in Java only consist of
      method signatures - they do not have any other constraints or
      invariants specified. Hence if I provide an interface IAccount, how
      can I be sure that the implementation instance that I receive during
      runtime honors all the constraints that all accounts should have.

      But OTOH, classes are not test-friendly. If I had interfaces, I can
      easily supply mock implementations for unit testing. Take the
      following example :-

      class Trade {
      private Account account;
      private Security security;
      // ..
      // ..
      }

      Here we have a domain abstraction that contains nested instances of
      other domain abstractions. If all of them are classes, then how do I
      unit test ? Or am I supposed to do unit testing of Trade with actual
      implementations of Account and Security abstractions ?

      Here I am assuming that all my services (data access, LDAP access
      etc.) are exposed as interfaces and I have mock implementations for
      each of them. But I am not very much convinced about domain abstractions.

      Any help will be appreciated.

      Cheers.
      - Debasish
    • Zhiyi Zhang
      I don t suppose I could define SOA. Anyone has his own favorite view. But let s look at what SOA tries to solve. The top two in my list: - Integrate systems
      Message 37 of 37 , Nov 5, 2006
        I don't suppose I could define SOA. Anyone has his own favorite view. But
        let's look at what SOA tries to solve. The top two in my list:

        - Integrate systems which couldn't talk to each other before.
        - Business funcationality reuse. For example, we don't want the customer to
        enter the same info twice.

        On the first one, the obvious is distributed computing based on open
        standard. The less obvious is to build common language among various systems
        speaking dialects, as Dmitriy mentioned in 'bounded contexts'.

        On business funcationality reuse, the challenge is how to decompose an
        enterprise into various business components, in other words, business
        functionality refactoring. I personally see DDD first and foremost as a way
        to distill a business or a domain, hence IMO, DDD is an essential tool.

        Allow me to go a bit further, I think DDD will work well with any
        architecture style.

        - z

        >From: Dmitriy Kopylenko <dkopylen@...>
        >Reply-To: domaindrivendesign@yahoogroups.com
        >To: domaindrivendesign@yahoogroups.com
        >Subject: Re: [domaindrivendesign] DDD and SOA?
        >Date: Wed, 01 Nov 2006 12:07:07 -0500
        >
        >I just want to express my opinion about that (SOA and DDD). I view SOA
        >simply as the way to "integrate" systems (subsystems or even perhaps
        >"bounded contexts") by means of course grained "services". Yes, exposed
        >service interfaces are in fact more "procedural" by definition, black boxes
        >if you will, with a well defined input and output contract. That I don't
        >think means that DDD, with a rich domain model, cannot be used internally
        >to implement exposed service for example.
        >
        >Let's say you need to "integrate" two "bounded contexts" in DDD type of
        >application. One bounded context could expose course grained service (via
        >Open Host Service or Anti corruption layer) etc. Internally, the
        >implementation would "translate" state of the service request (DTO, SDO, or
        >what have you) into more elaborate domain model to do its work, for
        >example, etc.
        >
        >So I don;t view SOA and DDD as two "competing" methodologies.
        >
        >As they say, just my 2c. :-)
        >
        >Regards,
        >Dmitriy.
        >
        >
        >Randy Stafford wrote:
        >>
        >>In one sense I view them as complementary architectural styles, in that
        >>there can be a DDD-style implementation behind a service interface. I've
        >>actually been building applications that way for a long time, although my
        >>application services weren't always "web services". That's part of the
        >>problem: what exactly is SOA, anyway? My favorite definition is in the
        >>OASIS Consortium's SOA Reference Model Technical Committee
        >><http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm>
        >>specification, and I finally concluded that an "SOA application" is one
        >>designed to contain, expose, or consume "services", in whatever technology
        >>they happen to be implemented in.
        >>
        >>
        >>
        >>In another sense I think "SOA", to the extent that Service Component
        >>Architecture and its embedded Service Data Objects specifications are an
        >>inherent part, is quite threatening to DDD as I know it. This is because
        >>SDO seems to completely divorce state from behavior in its model of
        >>"objects" -- there doesn't seem to be any provision for including and
        >>specifying domain-meaningful behavior of the "data objects" and "data
        >>graphs" it specifies. I view that as a step backwards, towards procedural
        >>code operating on dumb data structures, even though "data graphs" do seem
        >>to map nicely to the Aggregate concept.
        >>
        >>
        >>
        >>Randy
        >>
        >>
        >>
        >>------------------------------------------------------------------------
        >>
        >>*From:* domaindrivendesign@yahoogroups.com
        >>[mailto:domaindrivendesign@yahoogroups.com] *On Behalf Of *Tomas Karlsson
        >>*Sent:* Tuesday, October 31, 2006 11:03 AM
        >>*To:* domaindrivendesign@yahoogroups.com
        >>*Subject:* [domaindrivendesign] DDD and SOA?
        >>
        >>
        >>
        >>Hi,
        >>
        >>
        >>
        >>I know DDD and SOA have been asked for earlier -- but without reply. Does
        >>anyone has anything to add to such a thread now?
        >>
        >>
        >>
        >>/Tomas
        >>
        >>
        >

        _________________________________________________________________
        Try the next generation of search with Windows Live Search today!
        http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-us&source=hmtagline
      Your message has been successfully submitted and would be delivered to recipients shortly.