Question

In my system I have two different projects, one defining its interfaces and another defining its domain objects. So far I managed to have the interface definitions independent of the domain objects but I am feeling now the need to include certain domain objects either as parameters of the methods defined in the interfaces or as return values of such.

Should I resist and try to keep interfaces independent of the domain objects or is this a unfounded concern?

EDIT – after posting the question I thought about defining an interface for each domain object, this way they can kept separate – don’t know if it is overkill or if it is the price to pay so they remain independent.

EDIT # 2 – I was asked to give an example so I’ll try to keep it simple. I have a process that handles image transformation and one of my domain objects is a class that holds information such as resolution, list of pages, hash, etc. Let it be called DocumentInfo. I have a class that uses DocumentInfo to perform actions such as GeneratePdfFromTiff; I had defined GeneratePdfFromTiff first as an interface method of IImageHandler, which is then implemented by ImageHandler.

The problem is – one of the parameters to GeneratePdfFromTiff is DocumentInfo. Here I have the method defined at the interface level having to be aware of DocumentInfo which was defined at the domain level. This is the kind of dependency I am concerned about.

Answer 1

This is a tough one, I’ll give a try. +1 for the question.

Domain Models should know how to interact with each other’s inner workings if they do it in the real world I think. That, of course, depends heavily on your exact domain model, because different models of the same thing would come up with very different representations.

The issue with the interfaces for each domain model class is that your domain model itself is already a specific view on reality, just like the interfaces. An interface is only valid within that specific domain. You can’t use the same ICar for transportation planning, household-income calculators and car aerodynamics optimization.

Therefore, I doubt it is very useful to isolate their dependencies too far.

From what I know, interfaces are mostly (always?) public, which gives rise to access issues. The interface should not expose details about the implementation, but the domain model classes contain the actual implementation. Thus, instead of ‘just accessing some value’, you’d have to create another abstraction mechanism for each and every detail. You can’t, for example, access any ID, User, etc. in the system. You’d need an abstract ID type, an ID Provider, etc. I believe this could be extremely cumbersome in a large real-world model.

Certain ‘natural domain borders’ should still be isolated, of course. If you build a social text editor, all domain classes that would also occur in a traditional text editor should be completely isolated from the social-network related items. Thus, the text-editor should only know an IUser. But I guess I’m not telling you anything new…

This is not too satisfying I’m afraid, but it seems it is essentially a thin line to walk.