Where to put an object that is not an entity in the DDD

2

My project in ASP.NET MVC in C # has a Domain layer where I have entities, and business rules. I need to add a new rule where I should return an object with an internal list, but I ended up having a discussion about DDD rules with my colleagues and some defend the thesis that this object even being used by domains routines, can not stay in the Domain.

So I started using dynamic, but when I get to the automapper it has problems converting.

I would like to know the opinion of those who have more experience with DDD, or who can suggest a project, idea or solution to this problem.

Example:

A Estrutura é a seguinte:
1) Web
     Automaper
     View (Com Entidades do banco de dados e outas)     
2) Application
3) Domain
    Entites (Entidades do banco de dados)
    Services (Onde ficam as regras de negocios)
4) Repository 
    Dapper
    Entites Repository
5)Ioc

Now I need to create a routine that calculates certain information this I did in 3) Domain - > Service "FluxoService", inside I have the method that returns a list type "Flow" So "Flow" is not an entity and does not persist in the database, can this "Flow" object stay in the domain?

If you can not, how can I return data of this type "Flow"?

Another example: I made a select using dapper (4) Repository the return of this select I created a class called "MyData" To return to 1) Web I will need to go through 3) Domain - > Service (MyDomainService calls MyDomainRepository ((4) Repository) how can I return "MyData" to layer 1) if the "MyData" Class can not be put into the domain?

Maybe the solution would be to use subdomain? Does anyone use the same structure as mine? or to use will I have to change the structure?

Another example: MusicStoreDDD In this project Cart is an entity and place in the Domain Now I want to add Flow and FlowService that are not entities and do not persist

Can these be in the domain?

public class CartService : Service<Cart>, ICartService
{
    public CartService(ICartRepository repository, ICartReadOnlyRepository readOnlyRepository) 
        : base(repository, readOnlyRepository)
    {
    }
}

public class FluxoService : IFluxoService
{
    private readonly ICartService _service;

    public CartService(ICartRepository repository, ICartReadOnlyRepository readOnlyRepository, ICartService service) 
        : base(repository, readOnlyRepository)
    {
        _service = service; 
    }

    public List<Fluxo> ProcessarFluxo()
    {
        return new List<Fluxo>().ToList();
    }
}
    
asked by anonymous 14.07.2017 / 14:13

2 answers

2

Separating things:

  • Your Domain object should solve a business problem

  • Your AutoMapper object (must be in another layer) avoids the need to write extensive mapping codes, thus providing more agility in development and easier maintenance.

As far as I know AutoMapper knows how to map one object to another but does not know (and should not) about its business rules to create its domain object. That is, it is not it that will solve a business logic to bring an object with or without the internal list.

To know whether or not your new rule should be implemented in the Domain, consider the following: Is it a business rule?

Assuming that this is a business rule then you can handle the creation of this object on the object itself via a constructor, method, or DDD concept (when this object is too complex, which at first does not appear to be).

Example:

On the object you want to return, depending on the parameters you entered, either in the constructor or in a method, execute the logic and return a new object with or without the built-in list.

public class Objeto()
{
    public static Objeto NovoObjeto(bool comListaInterna)
    {
        if(comListaInterna)
        {
            // return Objeto com lista interna
        }
        // return Objeto sem lista interna
    }
}

However, if this business rule does not depend only on your Entity's information, but also on external services and repositories, instead of implementing those calls in the entity, you should use what the Services of DDD which is a class that solves business problems but is not a "natural responsibility" of entities or objects of value.

    
14.07.2017 / 15:47
0

The Domain layer in the DDD where all your business rules are located should not have any type of technology coupled.

But answering your question if by what I understood where you will get a complex object where it will return a list:

Example:

   class Pessoa
    {
        public int PessoaId { get; set; }
        public string Nome { get; set; }
        public IEnumerable<Produto> Produtos { get; set; }
    }


    class Produto
    {
        public string Nome { get; set; }
        public Pessoa Pessoa { get; set; }
    }

But now if you need to do an access to the bank you will not be able to do this layer. The autommaper problem can make DTO in the Bank access layer in the Infra.Data case and return your need within that new object.

    
14.07.2017 / 17:18