DDD: Supple Design

Supple Design (p. 244):

"A lot of overengineering has been justified in the name of flexibility. But more often than not, excessive layers of abstraction and indirection get in the way. Look at the design of software that really empowers the people who handle it; you will usually see something simple."

Evans goes on to say that the early version of software will probably be rigid and stiff. And that many do not even acquire the suppleness that he is talking about.

What Evans says is a good point. But it seems to be very hard to achieve. I have seen systems with a lot of overengineering and lots of accompanying abstraction layers piled onto it. It's hard to understand it all at first. But after looking at it for a while, trying things out and actually reading the source code, things are not that bad overall. And when you and the other developers get into this mindset where you understand the code so well, you find it really hard to be able to break out of the box and actually evaluate the complexity of the design. At least until it has become some big ball of mud and then no one knows what to do with it anymore.

In this chapter, Evans offers some patterns that lend suppleness to a design. Combined with the advice from the previous chapter on how to actually dig deeper at a domain model, this might be able to illustrate what a supple design is and how to achieve it.

Some of these refactorings that have been suggested are pretty small and some are more involved. But they do impact the overall readability and maintainability of the code. The most important thing when doing these refactorings is to understand the fact that these are only rules of thumbs. Refactoring is not a one way process in this case. Sometimes, a previous refactoring might work better and you would have to revert back to it.

Evans also metions Domain-Specific Languages in this chapter as a way to tie the model and the implementation more tightly. He cautions that while the binding between the model and the implementation might be better, it might be a maintenance nightmare to keep the domain-specific language in tune with the ubiquitous language. Also, certain languages like Scheme, Smalltalk and Ruby are more suited for domain-specific language than others like Java and C#.

1 puts Time.now #=> Tue May 10 17:03:43 CDT 2005 
2 puts 20.minutes.ago #=> Tue May 10 16:43:43 CDT 2005 
3 puts 20.hours.from_now #=> Wed May 11 13:03:43 CDT 2005 
4 puts 20.weeks.from_now #=> Tue Sep 27 17:03:43 CDT 2005 
5 puts 20.months.ago #=> Thu Sep 18 17:03:43 CDT 2003 

Domain-Specific Languages should be readable (verbally) and still make sense

comments powered by Disqus