Design issue with interaction between Service Layer and DAL Layer

Question

First of all, typically architectural guidance like the Onion Architecture and Domain Driven Design (DDD) do not fit all cases when designing a system. In fact, using these techniques is discouraged unless the domain has significant complexity to warrant the cost. So, the domain you are modelling is complex enough that it will not fit into a more simple pattern.

IMHO, both the Onion Architecture and DDD try to achieve the same thing. Namely, the ability to have a programmable (and perhaps easily portable) domain for complex logic that is devoid of all other concerns. That is why in Onion, for example, application, infrastructure, configuration and persistence concerns are at the edges.

So, in summary, the domain is just code. It can then utilize those cool design patterns to solve the complex problems at hand without worrying about anything else.

I really like the Onion articles because the picture of concentric barriers is different to the idea of a layered architecture.

In a layered architecture, it is easy to think vertically, up and down, through the layers. For example, you have a service on top which speaks the outside world (through DTOs or ViewModels), then the service calls the business logic, finally, the business logic calls down to some persistence layer to keep the state of the system.

However, the Onion Architecture describes a different way to think about it. You may still have a service at the top, but this is an application service. For example, a Controller in ASP.NET MVC knows about HTTP, application configuration settings and security sessions. But the job of the controller isn't just to defer work to lower (smarter) layers. The job is to as quickly as possible map from the application side to the domain side. So simply speaking, the Controller calls into the domain asking for a piece of complex logic to be executed, gets the result back, and then persists. The Controller is the glue that is holding things together (not the domain).

So, the domain is the centre of the business domain. And nothing else.

This is why some complain about ORM tools that need attributes on the domain entities. We want our domain completely clean of all concerns other than the problem at hand. So, plain old objects.

So, the domain does not speak directly to application services or repositories. In fact, nothing that the domain calls speaks to these things. The domain is the core, and therefore, the end of the execution stack.

So, for a very simple code example (adapted from the OP):

Repository:

 // it is only infrastructure if it doesn't know about specific types directly
    public Repository<T>
    {
       public T Find(int id)
       {
           // resolve the entity
           return default(T);   
       }
    }

Domain Entity:

public class MyComplexClass1
{
    MyComplexClass1 Property1 {get; }  // requred because cannot be set from outside
    MyComplexClass2 Property2 {get; set;}
    private readonly IService MyService {get; set;}

    // no dependency injection frameworks!
    public MyComplexClass1(MyComplexClass1 property1)
    {
       // actually using the constructor to define the required properties
       // MyComplexClass1 is required and MyComplexClass2 is optional
       this.Property1 = property1;
       .....
    }

    public ComplexCalculationResult CrazyComplexCalculation(MyComplexClass3 complexity)
    {
       var theAnswer = 42;
       return new ComplexCalculationResult(theAnswer);
    }
}

Controller (Application Service):

public class TheController : Controller
{
    private readonly IRepository<MyComplexClass1> complexClassRepository;
    private readonly IRepository<ComplexResult> complexResultRepository;

    // this can use IoC if needed, no probs
    public TheController(IRepository<MyComplexClass1> complexClassRepository, IRepository<ComplexResult> complexResultRepository)
    {
        this.complexClassRepository = complexClassRepository;
        this.complexResultRepository = complexResultRepository;
    }

    // I know about HTTP
    public void Post(int id, int value)
    {
        var entity = this.complexClassRepository.Find(id);

        var complex3 = new MyComplexClass3(value);
        var result = entity.CrazyComplexCalculation(complex3);

        this.complexResultRepository.Save(result);  
    }
}

Now, very quickly you will be thinking, "Woah, that Controller is doing too much". For example, how about if we need 50 values to construct MyComplexClass3. This is where the Onion Architecture is brilliant. There is a design pattern for that called Factory or Builder and without the constraints of application concerns or persistence concerns, you can implement it easily. So, you refactor into the domain these patterns (and they become your domain services).

In summary, nothing the domain calls knows about application or persistence concerns. It is the end, the core of the system.

Hope this makes sense, I wrote a little bit more than I intended. :)