Sunday, May 12, 2013

IDDD Tour notes (2/2)

This is the second and last part of my notes I scribbled down attending the IDDD Tour. The first part was published last week.

A better model
Even if you come up with a better model, the fact that it has been the ubiquitous language of the domain for decades proves that it works for them.
This quote bothers me a bit. There definitely is truth to this, but modeling an existing process often presents such a great opportunity to revise and improve it. Naked models don't conceal deficiencies, inefficiencies and aberrations. Exploring alternative models free of habituation, politics and legacy is dirt cheap, while the outcome could considerably benefit all. It seems such a shame not to take advantage of this. As with most things, know when to pick your fights.

Elegance
Elegance is for dressing, not for delivering software.
This is one to remember; I'll be using this one next time someone uses elegance as an argument for gold plating.

Cultivating models
Models grow; you will never have the best model from the start. Improve them every time you pass by.
Your first attempt at it is hardly ever right. Don't beat yourself up over it. The best models are the result of multiple iterations.
In general I consider dwelling on one problem too long to be a waste of time. Settle for good enough, and allow the better solution to emerge by itself over time.
When I feel a design is mighty important, I might accelerate this process by iterating over it multiple times in just a few days; asking for constant feedback, carrying the problem with me everywhere I go, always challenging it, and molding it in different shapes until one sticks.

Reuse
Lots of people use a shared kernel just for reuse. It's often not worth it.
People are so obsessed with the DRY principle, and the dogma of avoiding duplication, it often does more harm than good. Nonexistent concepts are introduced just to spare a few duplicate lines of code, while they will hinder and complicate autonomous evolution.

REST and DDD
Don't expose your domain model over REST: expose use cases. 
You want to enable relentlessly evolving your domain model without breaking clients. In practice you would post intent-revealing command resources, while hypermedia guides you in navigating to subsequent commands.

Published language
How is the language agreed upon; over lunch or by a committee?
 A great question which reveals if a language should be really considered as published.

And that's the last of it. If you thought some of these were interesting, you should probably get the book. I finished Growing Object-Oriented Software Guided by Tests last week, so I finally get to read it myself after having it collect dust for two months.

2 comments:

  1. Hi Jef, I am not very confident with the first stament either. And this is one fo the areas where my opinion diverges from others DDD practitioners.
    While it is true that for consolidated domains, an existing language might be the result of a darwinian selection resulting in a peak, I've seen many situations where models where simply compliant to a given behavioral plateau, with no big difference from company to company. Accounting or invoicing being typical example areas where many companies have the same problem, and where a reinvented solution might create more harm than good. Nevertheless, it is also true that these consolidated models are far from optimal, and often modeled around debatable paradigms. This area might be consolidated just because nobody tried a different model and expectations cooled down. But some value could eventually be there, sometimes.

    ReplyDelete
  2. I'm agreeing with Alberto. There are times when something is not modeled correctly. Instead, as a short-term solution, a column is added, and the code gets messier because someone didn't step back, take the time, and model it correctly. When two concepts are squeezed into one it gets unmaintainable.

    ReplyDelete