3 ms·
Both your comment and the article sound a bit like the inverse of the problem addressed by "Domain Driven Design". In the case of the book/approach, the proble
by mercer 6y ago
Both your comment and the article sound a bit like the inverse of the problem addressed by "Domain Driven Design".
In the case of the book/approach, the problem is that the IT side doesn't match the business side (in terminology, code organization, etc.). The solution is for IT to become more aligned with the rest of the company.
But in the case of your comment and the article, the mismatch seems to work the other way around. Out of some 'two-pizza methodology' or whatever, the business side now has to split up what should be a single problem/domain in a nonsensical collection of different domains.
I might be entirely off here, though. But if I'm not, is this problem perhaps particular to companies where IT is more in charge than in the types of companies where DDD has been a solution?