Limit your abstractions: Analyzing a DDD application

abstractions have a cost. you should limit them. that seems like an obvious statement, but in a recent discussion i had, i realized that i didn’t articulate things in quite the proper way before.

let me see if i can explain better now. one of the problems in typical applications is that we don’t really think before we introduce abstractions. for the purpose of this discussion, an abstraction in an interface. let us take a look at a sample ddd application.

nitpicker corner: no, i am not saying avoid using interfaces.

i took all the interesting interfaces out of the application, you can see them here:

take a look at the interfaces below. they bother me. they bother me because each of them represent an abstraction that is specific for a particular problem. in other words, it represent an non-abstracted abstraction, if that make any sense.

as i said, this is taken a ddd sample application . it isn’t a big one (and no, i didn’t review the actual code to see if it is a good one), but the interfaces that it has reveal a common problem, namely, interface explosion, or over abstraction. i removed any infrastructure / persistence stuff that was in the app, so you are looking just at the business interfaces, mind.

the problem is that the way this application is structured, it is highly procedural and had to maintain.

huh?! i can hear you say, procedural? this is a ddd app, just look at the names, we have services and facades and events and… those are all good things . this design is pretty much text book. how can you say that this design is hard to maintain?

i’ll answer this question (and propose answers) in this series of posts. in the meantime, feel free to look at the code (it is java, in its origin, and i simply modified it to c# for easier working) and make your own conclusions.

source: http://ayende.com/blog/153889/limit-your-abstractions-analyzing-a-ddd-application