4 votes

ASP.NET MVC architecture DDD (Domain Driven Design)

DDD(Domain Driven Design), Is a set of patterns, principles and practices that help us solve and understand the problems of the business(Domain) in the design of object-oriented systems. DDD is a very broad subject.

I am using the architecture N - Layers, from Windows Forms, but in ASP.NET MVC I have a question since I am a beginner working on web systems.

Enfoquemonos in the architecture DDD.

Domain Driven Design

We will direct you to the problem that I have. On the basis of which the entities of the domain are objects that have an identity and are important within the business logic of our application, but that does not have for to be known directly by other layers of the application.

This is the structure of my project.

Estructura N-Capas

I am using DTOs or Data Transfer Objects are classes whose main purpose is to simplify the objects to be exchanged between processes.

In the Application Layer, in which I have two projects: Service of Application and Adapters.

  • Adapters: it Is here where I have implemented my DTOs.
  • Application services: it Is in this layer where I implement the methods of the application, because my presentation Layer is ignorant of the Domain Layer and viseversa. Returning to the theme is in this layer where I do the magic that the Entities in the Domain are converted into Dots by means of AutoMapper.

Domain entities.

public class Proveedor
{
    public int ProveedorId { get; set; }
    public string RazonSocial { get; set; }
    public string Direccion { get; set; }
}

DTOs

public class ProveedorDto
{
    [Key]
    public int ProveedorId { get; set; }

    [Display(Name = "Razón Social")]
    public string RazonSocial { get; set; }

    [Display(Name = "Dirección")]
    public string Direccion { get; set; }
}

Applying AutoMapper on Application Services.

public IEnumerable<ProveedorDto> GetAll()
    {
        IEnumerable<Proveedor> _proveedor = _sdProveedor.GetAll();
        config = new MapperConfiguration(cfg => cfg.CreateMap<Proveedor, ProveedorDto>());
        IEnumerable<ProveedorDto> listDto = config.CreateMapper().Map<IEnumerable<ProveedorDto>>(_proveedor);
        return listDto;
    }

In this way, is that my Entities in the Domain do not reach to the Presentation Layer, and DTOs that are in the Layer Adapters are used as the Models of the MVC design pattern.

  • Do I have to create the Models in the Presentation Layer, I have to stick to the letter of the Models be implemented in that layer, as it says MVC?
  • How should I implement that part which I have explained, using good practices to be long-winded, my architecture?

3voto

cgonzalezr Points 21

I think it is important to have clear the difference between theory and practice. Throughout the application you'll find in many situations that can force you to break that theory in the pursuit of productivity and efficiency. Is already in you, as the architect of the application, to make that decision.

From my personal experience, the models do not paint anything in the presentation layer. I started keeping them in the persistence layer, which is his ideal place, to end in a layer transverse to all so-called "Infrastructure", because one way or the other, it was easy to end up needing the reference to it in other layers. In theory, everything related to persistence, models included, must be placed in that layer. The domain should not have any relationship with models or know of its existence.

If you are a purist of the architectures and you are able to reduce the coupling between layers to zero, you've reached the ideal architecture, but I insist that many times it is necessary to break those rules and do things with head. When you pass the time and take a lot of time working with the application, you will give account of the things which thou hast done well and that you have done wrong.

1voto

Carlos Cocom Points 226

Friend

In fact it is the opposite of all the application must know the domain. The idea behind DDD is to create a business model or a black box that works and solves problems specific to the business.

Then the focus is directed on creating an ecosystem where entities interact and collaborate.

The concept to make it more clear would be something like: the sun with its very existence has an effect, their light, their gravity affects the planets climate, so it must be every event that is present in the domain.

In your model, that should happen if I have an accounting system and an invoice must be entered to send the message to the model this should validate, affect other entities, and record, if necessary, or perhaps modify something.

All that logic is encapsulated in the domain in such a way that the operations are not the typical:

_repisitorio.bills.add(invoice)

if you do not

model.Bills.RegistrarFactura(bill)

In generates all the logic the encapsulas in a domain that is capable of processing operations pertaining to the same, which makes it very valuable.

It is also important to mention that a domain does not have to do with the persistence that you should be able to operate without the same even for a domain without persistence it is almost useless.

Now the reason for using transformations of domain objects to the user is that in mvc the results are to be made through a viewmodel and a domain of a concept can involve a kind of collaboration between the business entities which makes it no candidate to represent for the user.

for example you could have a purchase order and its items and the user since the ui will display the purchase order and the quantity of items, obviously this has to be process and result to fill a viewmodel ready to display

Another important concept is that by being focused on a Domain already does not speak of concept-isolated example before it was typical for something like entities

Emp is now Employed. Simple, no?

Entities must be common among all the people on the team is what is called language is Ubiquitous, it can be said that the colloquial language should not be abstraciones as before was happening if not that you should be able to talk with the expert in business of the same concepts.

It is also important for modeling the domain this is not born in your head, the domain of a business because there is always, what is done is to speak with what you know the business and then this is passed to the code, that is why it is important to understand well how it works if it is not possible to leave empty and therefore not be able to solve all the problems.

Reviews the book by Eric Evans, Domain Drive Design

We will direct you to the problem that I have. On the basis of which the entities of the domain are objects that have an identity and are important within the business logic of our application, but that does not have for to be known directly by other layers of the application.

Fake, look at all levels but does not necessarily have to know the user.

  • Do I have to create the Models in the Presentation Layer, I have that beat me the letter that the Models be implemented in that layer, such it says MVC?

    As implemented in mvc has nothing to do with ddd, but an important point, the actions are very related to a view model which, as its name says it is a model to the view or the page which has nothing to do with your domain so that your reason for being is the view or the page and this is a concept handling in mvc.

  • How should I implement that part which I have explained, using good practices to be long-winded, my architecture?

    There is a recipe you have to documentarte.

HolaDevs.com

HolaDevs is an online community of programmers and software lovers.
You can check other people responses or create a new question if you don't find a solution

Powered by:

X