I have been searching and reading recently about DDD and, so far, I think I understood its fundations.
If I understood well, the architecture is similar to this:
Database <--SQL--> DAO/ORM <--CRUD--> Repository/Aggreagtes <--Business--> **¿?** <-- Controller --> Internet/Client/UI
My doubt turns around the ¿? gap. I usually fill it with services.
My services often are the first evidence of a Anemic Domain Model, because all the business logic is at these services (and their implementations are quite procedural). In consequence my domain model is a mere set of POJOs.
My intention is to move gradually my current project to a richer domain model and a thinner service layer. However I'm concerned about the transactionality and the layer it belongs to.
Searching about how to fill up the above gap, I have found this question
Following the link and the checked answer I assume that:
There're still services in DDD. These servicies performs business operations via repositories (and aggregate roots).
The services are meant to cover the business needs that can not be covered through agreggate roots and/or repositories.
The services execute business transactions through UnitOfWork (UoW) components. A UoW might involve one ore more aggregated roots and repositories.
Question: Is this the way to implement the business layer and the transactionality in DDD? (App Service -> UoW -> Repository)
[Bonus question]: How the application events and handlers fit in such architecture? Are the services translated into handlers? (Handler -> UoW -> Repository)?
I am grateful for any kind of input. I feel kinda confused with how ddd layers are tied or how to tie them with the less coupling possible.