ASP.NET MVC architecture DDD (Domain Driven Design)

Navigation
4

DDD ( Domain Driven Design ), It is a set of basic and practical patterns that help us to solve and understand the business problems (Domain) in the design of object-oriented systems. DDD is a very broad topic.

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

Let's focus on the DDD architecture.

  

We go straight to the problem that I have. Starting from the entities   of the domain are objects that have an identity and are important   within the business logic of our application, but not   they have to be known directly by other layers of the   application.

This is the structure of my project.

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

In Application Layer , in which I have two projects: Application Services and Adapters .

  • Adapters: This is where I have implemented my DTOs.
  • Application Services: It is in this layer that I implement the application's methods, since my Presentation Layer is ignorant of the Domain Layer and vise. Returning to the topic is in this layer where I make the magic that the Domain Entities become DTOs through 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 in 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;
    }

This way, my Domain Entities do not reach the Presentation Layer and the DTOs that are in the Adapter Layer are used as the Models of the MVC design pattern.

  • Should I create the Models in the Presentation Layer, do I have to stick to the letter that the Models are implemented in that layer, as MVC says?
  • How should I implement that part that I have explained, using good practices so that my architecture is neat?
asked by Pedro Ávila 01.01.2017 в 20:16
source

2 answers

2

I think it is important to be clear about the difference between theory and practice. Throughout the application you will find yourself in many situations that may force you to break that theory in pursuit of productivity and efficiency. It is up to 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 by having them in the persistence layer, which is their ideal site, to end up in a transversal layer to all called "Infrastructure", since in one way or another, it was easy to end up needing their reference in other layers. In theory, everything related to persistence, including models, must be located in that layer. The domain should not have any relationship with models or know of their existence.

If you are a purist of architectures and you are able to reduce the coupling between layers to zero, you will have reached the ideal architecture, but I insist that it is often necessary to break those rules and do things with a head. When time passes and you have been working with the application for a long time, you will realize the things you have done well and the things you have done wrong.

    
answered by 19.01.2017 в 12:10
1

Friend

In fact, the opposite is true: the entire application must know the domain. The idea behind DDD is to create a business model or a black box that works and solves business problems.

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

The concept to make it clearer would be something like: the sun with its own existence has an effect, its light its gravity affects the planets the weather, this must be every event that occurs in the domain.

In your model that must happen if I have an accounting system and an invoice must be entered when sending the message to the model, this must validate, affect other entities and register if necessary or maybe modify something.

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

_repisitorio.facturas.add (invoice)

otherwise

model.Facturas.RegistrarFactura (factura)

In general all the logic encapsulates a domain capable of processing its own operations which makes it very valuable.

It is also important to mention that a domain does not have to do with persistence because it should be able to work without it, even if a domain without persistence is almost useless.

Now the reason for using transformations of domain objects to the user is because in mvc the results are made through a viewmodel and in a domain a concept can involve a type of collaboration between business entities that does not makes it a candidate to represent facing the user.

For example you can have a purchase order and its items and the user from the ui the purchase order and the number of items is displayed, obviously this has to be processed and the result will fill a viewmodel ready to visualize

Another important concept is that being focused on a Domain no longer speaks of isolated concepts, for example, it was typical to have entities such as

Emp is now Employee. Simple, no?

The entities must be common among all the people of the team is what is called Ubiquitous language, it can be said that the colloquial language should not be abstractions as before happened if you should not be able to talk with the expert of the same business concepts.

It is also important that to model the domain this is not born in your head, the domain of a business already exists, what you do is talk to what you know the business and then this is passed to the code, so It is important to understand well how it works if you can not leave empty and therefore can not solve all problems.

Check Eric Evans' book, Domain Drive Design

  

We go straight to the problem that I have. Starting from the entities   of the domain are objects that have an identity and are important   within the business logic of our application, but not   they have to be known directly by other layers of the   application.

False, they are seen at all levels but not necessarily the user has to know.

  • Should I create the Models in the Presentation Layer, I have to hit myself to the letter that the Models are implemented in that layer, such What does MVC say?

    As it is implemented in mvc it does not have to do with ddd but an important point, the actions are very related to a view model that as its name says it is a model of the view or of the page which has nothing what to do with your domain because its raison d'etre is the view or the page and this is a concept driving in mvc.

  • How should I implement that part that I have explained, using good practices so that my architecture is neat?

    There is no recipe you have to document.

answered by 19.01.2017 в 16:25
Obtain value of a JSON object according to the value of another JSON object Create and plot fix of slopes between points