I completely agree. At the early stage of service development I was recently in charge of Judging that this service will clearly continue to be domain-advanced I have refactored everything using DDD patterns. And as expected, the service rules are becoming more and more complex, but thanks to the well-prepared bounded context boundary definitions and Ubiqutous language definitions at the start, it hasn’t gotten messy and Claude is still developing it.

The cost of writing code is now converging to zero, but Communicating with people and setting precise boundaries and language settings for the service is I believe that it is still an extremely remain role for developers.

My concern is that none of our services have applied the DDD pattern. I can’t even refactor the existing legacies If they could build the service again, they would have strongly insisted that everything be built using DDD patterns...

I look forward to the next article.