Much though I dislike the author, I actually recommend the Clean Architecture book as an on-ramp for this stuff. CA is very similar to Hexagonal Architecture, a

Much though I dislike the author, I actually recommend the Clean Architecture book as an on-ramp for this stuff. CA is very similar to Hexagonal Architecture, and the book is more specific than any other source I've yet come across. It's written exactly with the goal in mind to tell you, clearly and unambiguously, what you should do and why, with as little room to manoeuvre as possible. That does make it a bit polemic, but when you're learning that's what you need. It's also worth looking at Vaughn Vernon's books on DDD. The problem there is that what you end up building if you follow them to the letter ends up looking a lot less like the sort of applications that teams are used to building (which is good! The value is proportional to the level of surprise) so getting buy-in at the right stage of the process to do it properly can be hard. You need to get in at the conception stage, so if your team is used to having ideas dropped on them even partially formed, the struggle is entirely non-technical. If you try to sell DDD as "how to structure the code we're going to write now that the problem has been thought through" it's not going to work.