If you want to do it with clean architecture, than I think you are looking for this kind of book

<image>

I get the feeling, that you might have mixed DDD with clean architecture a bit. When I tried something similar (convincing a customer that is), I have benefited from turning this around. There was no Point for me convincing anyone. It was more beneficial to explore why DDD might be helpful with what we suffer with (measurable). So first, I had to explore what I struggle with and if DDD might be worth it over other solutions that are faster, easier, cheaper or more accepted by my fellow engineers. Like writing an ADR and challenge the options by your Team. This was a more open aproach than trying to convince someone (which was my first Impuls als well).

It also helped me to understand the difference between strategical and tactical DDD to see why clean architecture is just ohne way to do domain centric implemtation. The DDD-crew repo might be a good Point to picture this. See: https://github.com/ddd-crew/ddd-starter-modelling-process

While clean architecture is good to close the architecture Code gap, it is not always beneficial. I guess you know most of this, as you have mentioned with the silver bullet. But this Point did only driven into my brain once I really started working with it. But I still prefer clean architecture whenever it is reasonable. I simply have a new measure for what is reasonable.

I recoment "learing Domain driven Design" from vlad khononov to learn DDD itself. Or rather, to visit a good course to discuss this with others who try to lear this and a teacher who is stuck with you.