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