What is the correct way to register one to Many with DDD

Asked

Viewed 101 times

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?

  • 1

    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.

  • 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

  • 1

    This project, despite being in ASP.NET Core, and a great example of great Bats like DDD. Equinox Project.

  • 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.

No answers

Browser other questions tagged

You are not signed in. Login or sign up in order to post.