[golondon]

The problem I see is especially in small / mid level companies' contexts, directly trying to jump to DDD usually ends up with a really weird, half-assed implementation. On top of that, it's usually hard to get people up to speed with this kind of architecture. If you're new in the domain, changes take longer as well. You can't go back to the white board every time, re-model your domain and do big changes to it every week.

With classical MVC + Transaction Scripts you can go quite a long way, as boring as it is it can scale up to 500 people working on it. When the time comes, you will have waay more knowledge to your domain and would be able to go with this kind of approach while going towards service oriented architecture or while implementing those boundaries within your monolith like Shopify does.

Otherwise you just waste your time for the things that don't give any benefit to you in short / mid term at all. On the long term nowadays it's really rare people stay at job that long or if that time comes your company will have enough money to throw money into the problem.

[pydry]

The bigger problem I saw wasnt getting people up to speed but:

* The patterns dictated by DDD typically ballooned the amount of code sometimes by up to 4x - usually due to all the added indirection.

* This meant some architectural mistakes took 4x as long to fix. If you misplaced your bounded context borders in particular you were fucked.

* It reduced programming to a bit of a religious exercise where instead of having productive discussions about benefits and trade offs we argued about the "right" way to do DDD.