More thoughts on the domain model

I wanted to write this down, because while “important” may overstate the case a bit, it occured to me that two separate threads of thought had converged into the same thing.

Thought number one I first heard at Jimmy Nilsson’s software summit in Malmo. Mats Helander said this radical thing that floated like a lead balloon, at least in my mind 😉 He said that there should be no business logic in the domain layer. Of course he also meant this in the context of what a O/R mapping tool should provide. Translation, don’t expect your mapping layer to implement your business logic. Makes sense. And, O/R tools make the manipultion of entities easier. In reality, the manipulation of entities is easy enough for generated logic to do. It’s tedious to do by hand, and many people are happy with the “domain layer” that O/R tools assist in developing.

Thought number two was something that hung on from my last blog. If property setters and getters are pretty weak toolage in the developers toolbox, what remains of the domain layer? In that blog, I said that that it was the assembling of business logic into a domain layer that remained of value.

Fast forward and combine these two ideas. You move from the idea of hand coded, statically typed domain objects containing state and behavior, to entities produced by generative techniques combined with dynamically constructed domain objects assembled for each use case, all dynamically typed with interfaces. OK, that’s a mouthful.


Comments are closed.