Where to place a non-entity object in the DDD

Question

My ASP.NET MVC project 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 Dominio routines, can not stay in Dominio.

So I started using Dynamic, but when arriving at automapper it presents problems for conversion.

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, this "Flow" object can be in Domain?

If Can’t, 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 the 1) Web I will need to go through the 3)Domain -> Service (Meusdadosservice calls Meusdadosrepository((4) Repository) how can I return "Mydata" to layer 1) Web if the "Mydata" Class cannot be placed in Domain?

Maybe the solution would be to use subdomain? someone uses with the structure similar to mine? or to use will have to change the structure?

another example: Musicstoreddd In this project Cart is an entity and will be in the Domain Now I want to add Flow and Fluxoservice that are not entities and do not persist

These can be on 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();
    }
}

Answer 1

Separating things:

• Your domain object should solve a business problem

• Your Automapper object (should be on another layer) avoids the need to write extensive mapping codes, thus providing more agility in development and facilitating maintenance.

As far as I know Automapper knows how to map an object to another but doesn’t know (and shouldn’t) about its business rules for creating your domain object. That is, it is not he who will solve a business logic to bring an object with or without the internal list.

To find out whether or not your new rule should be implemented in the Domain do the following analysis: it is a business rule?

Assuming then that it is a business rule you can treat the creation of that object in the object itself via a constructor, a method or using the concept of Factory DDD (when this object is very complex, which at first does not seem to be).

Example:

In the object you want to return, as the parameters are specified, either in the constructor or in a method, run the logic and return a new object with or without the internal 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 depends not only on the information of your Entity, but also on external services and repositories, instead of implementing these calls into the entity, you should use what the concept of Services DDD which is a class that solves business problems but are not a "natural responsibility" of entities or objects of value.

Answer 2

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

But answering your question whether from what I understand where you will have a complex object where you 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 make an access to the bank will not be able to do in that layer. The autommaper problem can do DTO on the Database access layer in the Infra.Data case and return your need within that new object.