• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Righting Software: avoiding domain decomposition

Posts: 15815
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another question related to the book sample at https://www.informit.com/articles/article.aspx?p=2995357 on Software Design Decomposition.

In the same article, you also discussed the problems with Domain Decomposition, again using the house building analogy. I think the analogy is a fairly good one and it also resonates with things I have seen happening in real world systems. There's a very popular and often-cited book by Eric Evans called "Domain-Driven Design" (DDD) which made the term "Ubiquitous Language" fairly, well, ubiquitous in certain design circles. Are Evans' ideas on DDD similar to or perhaps the same thing as what you refer to by Domain Decomposition or are there differences?

A follow up to that is what is your experience with systems that have been designed with DDD? While I don't have first-hand experience with DDD on a large-scale enterprise system, its proponents claim great success (naturally, I suppose). I just wonder if your mileage has varied from those who claim success and if so, how drastically has it been different?
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

The nature of the universe prevents functional decomposition from ever working (there is no free lunch).
As the book explains, domain decomposition is still functional decomposition, but in disguise.
Therefore, by the nature of the universe, domain decomposition is precluded from ever working, as is evident with the monstrous balls of mud it often leave in its wake.

The only case where common domain decomposition can work is if the business domains map to areas of volatility, but that is just not the way most businesses are structured.

Interestingly enough, if you were to do non-business domain decomposition, that often is a good start.
For example, a domain decomposition of myself would include author, speaker, architect, father, husband, etc.
That will create a ball of mud, with all the internals and the external interactions between the endless domains, and I suspect you have seen that.
But a non-business domain decomposition of me would include the nervous system, the cardio-vascular system, the skeleton, the urinary tack, the digestive track, etc.
But these are also my areas of volatilities, and I preform the required business activities by integrating it all (see Chapter 4 on Composable Design).  

Consider Paul's rocket mass heater.
    Bookmark Topic Watch Topic
  • New Topic