I'm worried I'm adding too many interfaces

Question

I am building out my domain model and continuing to refactor it. As I do, I am finding that I like interfaces as it allows me to create reusable methods/controllers/views for c

Answer 1

Don't create interfaces that you don't foresee an imminent need for. Observe the YAGNI (you ain't gonna need it) principle. Otherwise you'll wind up with needlessly complicated code.

Answer 2

I think your problem is that you are trying to shoe-horn your domain model into whatever gui that you're displaying data in.

Instead, consider your domain object things that have behaviour close to data and in its c'tor, give it an Action<DomainEvent>. Now, make sure that you ONLY EVER pass data OUT from a domain object through this action.

Now, you listen. Whenever you actually want to make a change to your domain, call a method on it. Let your GUI be updated through the Action<DomainEvent> by taking these events and saving them to whatever read model that you are interested in.

Have a look at http://www.infoq.com/presentations/ffffd-eric-evans and consider his points about domain events.

Now you don't have to add strange interfaces related to a technical domain into your business domain anymore. And remember; if you are doing CRUD like your examples show, then you are NOT doing domain driven design. You have an anemic domain.

Final point: use interfaces for things that actually need to be interchangeable. Are you carrying around a lot of INamed things in your application that can be interchanged with one another?

Let me also link this, for you to consider:

• http://lostechies.com/jimmybogard/2011/10/11/event-sourcing-as-a-strategic-advantage/
• http://lostechies.com/jimmybogard/2010/04/08/strengthening-your-domain-domain-events/

Answer 3

The fact that you are using interfaces is a good thing. However, you should ask yourself, if I create an IEnabled interface, will I ever reference my class by that interface alone? i.e. will there be contexts where I interact with my class purely via the single property that interface exposes?

Also, can you consider contexts where you will interact with multiple implementation of this IEnabled interface?

If the answer to both of these question is "no", then the interface serves very little purpose.

Having said that, please don't worry too much about this! it does very little harm.