speaking of which, ddd is the only application I have installed that relies on motif...
Reading wikipedia it looks like one of those trivially stupidly obvious concepts wrapped in overly wordy academic terminology where they invent imaginary distinctions that have no differences in lived reality.
Like this from wikipedia: "An individual bounded context leaves some problems in the absence of a global view. The context of other models may still be vague and in flux.
People on other teams won't be very aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections. When connections must be made between different contexts, they tend to bleed into each other."
I mean holy hell, did a markov chain write that?
Let me translate: "yo, some specs are more locked down than others so try to make the code more flexible for the parts that are likely to change" that's it.
In my experience people that wrap simple stuff in academic potpourri get absolutely nothing done and generate really defective bloated software at very high cost because their code is written in the same way: simple things done in confusing and incomprehensible ways.
It's as if someone covered something as dumb as rocks with the maximum amount of bullshit possible where you can still just barely translate it to comprehensible English.
I'm surprised there's no set theory equations in that wikipedia page, maybe a bit of lambda calculus. We should get on that.
In fact, let's make a tool where you define your contexts in Haskell and then run it over your code like a linter to generate GraphML files so someone can run it through graphviz and print it out to put it on their wall to have in the background during their stand-ups so they can make themselves look super professional. Who cares if your deadlines slipped another month, you're clearly an authority!
Other industries, like hairbraiding require certificates and licenses to protect their jobs. In software, instead, apparently, some people ornately festoon simple things with fancy language and hide it behind acronym soup.
Go work on harder problems, seriously
It has flow charts, diagrams, tabular statistics, you know, to conclude groundbreaking things like "talking to at least one customer before releasing a product is a smart idea" or "don't waste time on unimportant things"
I'm like "Dude, did you just want a section for your CV that says 'Recent Publications'?"
Some things are genuinely complicated and others are intentionally so.
This is clearly something that is complicated by choice, not by necessity.
All that "complicated by choice" leads to is fundamentalism and orthodoxy. People worry about whether their code matches the new sacred scripture over whether it works and then they shoehorn things into the form that don't belong there.
They bake meaning onto code that's way out of scope of the project. It's like programmers Gematria.
I've seen these all-knowing preachers write broken code and leave unmaintainable dumpster fires in their wake my whole career. Giant cathedral messes that barely do anything that all the customers complain about with endless academic blabbering everywhere and very little to show for it.
It's a "type", more rare than others, but they're out there.
If the results are better and the systems work sign me up. But if it's just another church of code with mere ceremony and internal logic, then yeah, have fun at mass.
There's a serious lack of scientific rigour in these areas, and from my experience, it's heavily driven by popularity. Besides, i still don't see a reason why you could not explain things in simpler terms.
If you get smart people together who can communicate well, think for themselves and don't stand in their way, it will always outperform any method. But this is so painfully obvious, that no one will pay you to say that. And there's really no cookie cutter recipe to achieve that, anyone who tells you otherwise, probably has something to sell.