Domain-specific Interfaces

Question

Are there any real benefits of using interfaces over abstract classes in a domain model? Does anyone have any experience using interfaces in a domain model in a real project?

From a technical perspective, DDD defines stereotypes like aggregate, value, repository, etc. Repositories then, for example, can be defined as interfaces like ICustomerRepository which are then implemented by the infrastructure. Now that's a valid use case for an interface, since there can be multiple implementations of the repository (mocks, fakes etc.). However that is an entirely technical reason for using it: here the interface is only used to separate domain-specific repository from its technical implementation.

But what about purely domain-specific interfaces? Has anyone ever encountered a situation in which both the interface and its realization were non-technical? In particular, what reasons could speak for choosing an interface over an abstract class when implementing a domain-specific type? Maybe when multiple inheritance is involved it would be required, but how probable is it and could it be considered a good design then?

Answer 1

Does anyone have any experience using interfaces in a domain model in a real project?

We have lots of interfaces and there's a big problem with several of them; and that is temporal coupling - and unknowable coupling at that....

Should have been a templated abstract class

The interface method sequencing and code structure in the actual implementation makes it clear that without knowing how the methods are supposed to interact that it is impossible to implement the interface at all. Not only what methods call what other methods, but under what conditions, and with particular necessary details w/in individual methods.

After seeing the 3rd implementation it is clear that there is a refactoring screaming to get out but cannot due to what happens to code given:

• the ravages of time
• different coders
• and worst of all different coders at different times, especially given inevitable staff turn over.

Subsequent implementations are "different without being distinctive"

The first implementation was mimicked - I am not saying cut and pasted necessarily - by the next, and next, etc. implementation with the inevitable consequence of slight differences that at close (and time consuming) inspection prove to be merely differences.

Maintenance is dis-enhanced in several ways

1. The absence of an abstract class structure encourages gross violations of single responsibility principle.
2. This thing becomes the poster child for DRY.
3. True functional commonality is hidden by the irrelevant implementation differences and the SRP violations.
4. Inevitability some implementation reveals a common bug but is fixed only where the bug is reported. This is not surprising to anyone working large projects.
5. Inevitability some implementations introduce bugs that would have been prevented by an abstract class with foundational implementation and error handling.
6. Refactoring becomes (a) too time consuming (b) too risky (c) generally impractical