Sisyphus Problem

  • Why developing software feels like doing the same thing over and over with slight variations?

  • Why code reuse remains mostly a myth?

  • Why is writing code so efficient with copy-pasting or LLM generating —yet still requires so much manual checking and tweaking for each copy?

  • Why code size is so much larger than the common-sense description of a business problem it is supposed to solve?

  • Why does source code fade from memory so quickly—and why does the effort of understanding it feel comparable to rebuilding it from scratch?

  • Why does adding features and changes takes so much time and effort even though we are doing the same business for so long?

  • Why the larger a software system becomes, the more time and effort it takes to implement even a small change?

  • Why creating a software to solve one business problem creates so many new technical problems that have to be addressed?

Black Box Problem

  • How does one know what the software does without reading the programming language source code ?

  • Why even after reading the code it is still so hard to understand what it is about?

  • What is the business impact if a software component stops working?

  • Why are the error messages and stack traces are so cryptic and it is impossible to interpret on the business level?

  • How can I be sure that the software actually works before running it in a live environment?

  • How do I know what a running software just did and what is it about to do next?

  • Why is it impossible to tell at a glance whether a piece of code does something purely technical or contains any business logic?

  • Why do we need such complicated solutions just to understand what an application is doing? The time and resources spent setting up logging frameworks, collectors, reformatting pipelines, storage, and querying often outweigh the actual business value of the software component itself.

  • How is it possible that a piece of code has so many degrees of freedom that, while writing an application to check inventory, one could also implement bitcoin mining in the background?

Humpty-Dumpty Problem

  • Why does enterprise application integration demand so much effort? Where did the dis-integration happen in the first place?

  • Why is breaking systems into pieces—through “decoupling” or “microservices”—presented as best practice, when in reality it generates even more complexity, which then requires yet more software just to manage it?

  • Why does the same structure originating in the business domain have to be re-coded idiosyncratically many times—in different pieces of code, databases, messages, tracing frameworks, UIs, log queries, and so on? Why can’t there be a single encoding format shared across all use cases?

  • What is the origin of the so-called ‘state explosion’ problem that often comes up in attempts to formalize software design?

Motivating Problems

The motivation for DCM came from seeking answers to recurring questions, which themselves stem from underlying problems in current software development practices.

Crystal Ball Problem

Headless Horseman Problem

  • On whose behalf does software execute some business logic?

  • What are the parties impacted when a software component stops working?

  • Which business party is the software impersonating when it sends a message, and to whom is it actually communicating—that is, not the server or other technical recipient of the message, but the real business entity being addressed?

  • Why software estimates almost never work ?

  • Why can’t we reliably predict the impact of a software change?

Doppelgängers Problem

  • Why the same concept from the business domain gets so many independent replicas scattered around code and running software requiring a lot of effort trying to reconcile these and making it very hard to change the business domain thing because it implies finding and changing all the unlinked replicas?

    This is essentially a violation of Leibniz's Principle of the Identity of Indiscernibles.