Response to Clemens

It's almost time for my vacation, but I couldn't resist writing a blog post in answer to the post by Clemens Vasters called "Rows and Columns + Elements and Attributes is all you need". Not that I think I can teach Clemens anything of course, but I'd like to try some off-the-cuff arguments. And if the arguments don't work out, I can work on them during the vacation. Hey, Clemens probably set a trap with that blog post, but traps that nobody walks into are no fun, right?

So, here are some comments in no particular order:
  • Perhaps the whole discussion is about what is the best paradigm for business applications, OO/Domain Models [Fowler PoEAA] or some other paradigm? The choice of paradigm depends on many things, including what feels most natural for the developer.

  • I can't say I use implementation inheritance very much in my Domain Models, but there are times, for instance, when I find that Strategy [Gamma GoF] will make the Domain Model clearer. Implementation inheritance is just another tool that is in no way useful all the time, but can be sometimes. (The tool called interface is probably more useful much more often.)

  • I think implementation inheritance might be what I decide on during Refactoring to avoid code duplication, for example. It's not extremely common, but it happens.

  • When communicating with coarse granular SOA-like services, I agree with Clemens. There we should use documents with "global" and totally visible data. However, within a service, I still believe it's a good idea not to let data be global, but rather as much encapsulated (or rather information hidden) as suitable. Global data just won't be as efficient when it comes to robustness and maintainability as encapsulated data and the risks of side effects are typically greater.

  • When the merits of SOA are discussed, and how much better it is than Domain Models I think a very common misconception is that SOA and Domain Models not in the least bit apples and apples. For example, for a complex service, there can of course be a local Domain Model. Just because you use Domain Model, it doesn't have to be one huge monolithic one, it can still be used in an SOA-world…)

  • I think an example that is more complex than the one about Address, typically a behavior heavy Domain Model or one with advanced relationships, might make it easier to justify encapsulation and implementation inheritance, especially if we are trying hard to avoid duplication.

  • It may be naïve, but I still believe that traceability from analysis, or at least early model-driven design (which is pretty similar to OOA), down to code (both ways) is a good thing, at least as something to have as a goal.

  • I agree with Clemens that code reuse of classes such as Customer is hard to achieve between dissimilar projects. I'm pretty happy if I can get by with just one Customer class per project and just one instance of a piece of logic instead of having it duplicated several times. I think it's easier to achieve this last part if the behavior and data are attached to each other when appropriate, especially in projects with several developers.

  • On the other hand, between similar projects there might be greater chances of code reuse between the projects. This is what the idea of Software Factories is about.

  • I'm currently quite strongly influenced by Domain-Driven Design [Evans DDD] which is why I use, for instance, Repositories, Factories and Services quite a lot in my Domain Models. In a way you could think of those patterns as different kinds of services, just carefully classified. So that is probably pretty close to what Clemens said.
Did you like any of the arguments? Dislike any? Any you would like to add?

Having said that, I must state that I'm allergic to silver bullets, "this is all you need", "this is always best" and things like that. I know, you've probably got the feeling that I think Domain Model is always best, but that's really not the case. Heck, I've spent most of my professional life working with other paradigms, most of which have been very data oriented. Oh, and only yesterday I got a new project for optimizing the sprocs in a family of applications.