DDD strikes me the software version of Agile sometimes. The ideas and philosophy behind are good, but ends up being taken as a silver bullet. If you do this you will have a good architecture and your software will be well architected.
Especially in the .NET world i've seen DDD being branded together with CQRS as "Clean Architecture" which in reality turns out to be a mess of layers and separations.
arkh|4 years ago
DDD is more about managing your business software needs than making software. If you read "Implementing DDD" a good thing to take from it the fact you should focus your efforts on your business core value add. It's where you put your best developers, architects and money. Anything outside this core will get less resources and can often be outsourced.
And to evaluate what is this core and what is needed, you need your technical team to speak often with the domain experts. Using some common language.
The coding aspect is itself agile as usually there will be miscommunication at first between your tech team and your expert giving you a less than good result. More communication, more knowledge shared and understood will make you think differently about your product and its architecture: that's when you refactor.