1
I have studied DDD and assembled an architecture similar to the books and examples I have read.
So far, when I’m gonna crud, when I record I run something like this:
UI : The display layer fills an object with the screen data ( DTO, Viewmodel, command) and calls the interface layer
Interface : The interface layer (facade) transforms this object with screen information into an object of domination model and draws the application layer
Applying : The application layer receives this object that is part of the dominance layer and calls an infra repository
Infra : The infra layer (repository) persists the object in the database.
1st question: This architecture is legal or outrageously wrong?
While this division is reasonably acceptable, my cruel doubt is as to the crud of a domain model that has children (One to Many), for example:
A registration screen of Pedido
with various order items PedidoItem
which must be registered at the same time.
Question 2
How do I assemble this object? I fill a viewModel up there in the layer of UI ( Pedidoviewmodel and list ) and only when the order data is all assembled do I send this guy down (application layer) to be transformed into a domain object (Request) ??
OR
I hold the instance of the domain object (Request) in the application layer and insert item by item ( through the Pedidoitemviewmodel ) on the same layer?
Despite the good intention of developing oriented domain, you have not yet managed to escape from BOLOVO. From a read in this article, he explains that DDD is not layered architecture. Should help you.
– Thiago Lunardi
There’s still more news for me =( ... but I’m trying to get rid of the old concepts. I’m looking for material to study. Vlw
– Jonathan
This project, despite being in ASP.NET Core, and a great example of great Bats like DDD. Equinox Project.
– Thiago Lunardi
I would choose the second option because the interface should not be overloaded, even for performance reasons. Another thing: if you want to talk about DDD, your "interface" layer is doing the work of the Application layer, and in DDD there is no interface layer and UI because UI is a kind of interface layer implementation.
– Caffé