1. When the application is using a *Repository* ( which is an *Infrastructure service* ), then *Repository interface* is defined within a *Domain layer*, while its implementation is defined within an *Infrastructure layer*, since that way *Domain model* has no outgoing dependencies.

a) If we're 100 % certain that a particular ( non-Repository ) *Infrastructure service* **InfServ** won't ever be called by any code within *Domain layer*, then I assume ***InfServ's** interface* doesn't need to be defined within a *Domain layer*?

2. Assuming **InfServ** won't be called by code within Domain layer ( and as such we don't need to define its interface within *Domain layer* ):

a) if **InfServ** will be called by *Application layer's Services*, I assume *Application layer* should have an implicit dependency on *Infrastructure layer* and not the other way around? In other words, both ***InfServ's** interface* and *its implementation* should be defined within an *Infrastructure layer*?

b) And the reason why it is better for *Application layer* to have a dependency on *Infrastructure layer* and not another way around is that *Infrastructure layer* can be reused by many applications, while *Application layer* is in most cases specific only to a single application and usually can't be reused by other applications?

c) If we are 100 % certain that no code within *Domain layer* will ever use a *Repository*, then we wouldn't need to define its interface within *Domain layer*?

**UPDATE:**

1)

> 
> Yes, however, the definition of domain layer can include application
> services which act as a facade over the domain. The application
> service usually references a repository and other infrastructural
> services. It orchestrates domain objects and said services to implement
> use cases.
> 
> 
> 

a)

> 
> ... which act as a facade over the domain
> 
> 
> 

Couldn't we argue that "regular" ( those I was referring to in my question ) *Application Services* also act as a facade over the domain?

b)

> 
> The application service usually references a repository and other
> infrastructural services.
> 
> 
> 

From your reply, it seems as if you're suggesting ( though you're probably not ) that "regular" *Application services* don't normally reference *Infrastructural services*, which in fact they do ( as far as I know )?!

2)

a)

> 
> I usually merge application services, as described above, into the
> domain layer.
> 
> 
> 

"Regular" *Application layer* is also part of a BLL layer, so couldn't we argue that it is merged with *Domain layer* ( it actually sits on top of *Domain layer* )?!

b)

> 
> I tend to adhere to the Hexagonal architecture style ...
> 
> 
> 

It appears Hexagonal architecture doesn't have the explicit concept of *Application layer* ( ie of *Application Services* )?

c)

> 
> Part of the benefit of declaring a repository interface in the domain
> layer is that it specifies the data access requirements of the domain.
> 
> 
> 

So we should include the *Repository interface* in *Domain layer* even if we domain code won't use it?

**SECOND UPDATE:**

2a)

> 
> If what you call a "regular" application service interacts with the
> domain, I think it is acceptable to make it part of the domain
> "layer". However, the domain should not directly depend on the
> surrounding application service and so it is possible to split them up
> into separate modules if desired.
> 
> 
> 

* I'm not sure whether or not you're implying that the design of *Application layer* ( in traditionally layered architecture ) is any different from when you merge *Application layer* with *Domain layer* using, for example, *Onion architecture*?
* I'd say at least as far as modules are concerned, the two shouldn't be different, since in both cases we can separate *Application* and *Domain layer* modules? ( though I must confess I skipped the chaperon modules ( Evan's book ) since I didn't think I'd need that knowledge so early into learning DDD :O )

2b)

> 
> Yes because it can be contrasted with a layered architecture. A strict
> layered architecture does not gel with the idea of declaring
> repository interfaces in domain layer and implementing in
> infrastructure layer. This is because, on the one hand, you have a
> dependency in one direction, but in terms of deployment the dependency
> is in the other. Hexagonal addresses these concerns by placing the
> domain at the center. Take a look at the onion architecture - it is
> essentially hexagonal but may be easier to grasp.
> 
> 
> 

I don't yet know the MVC pattern or Asp.Net MVC, but regardless, from reading the first three parts of the series ( which confused me to the point I stopped reading it ), it appears :

a) From [Onion article](http://jeffreypalermo.com/blog/the-onion-architecture-part-1/):

> 
> Each layer is coupled to the layers below it, and each layer is often
> coupled to various infrastructure concerns.
> 
> 
> 

The author is implying that in traditionally layered architecture TLA a *Domain layer* is coupled to *Infrastructure layers*, which certainly isn't true, since we normally define *Infrastructure interfaces* ( such as *Repository interface* ) within *Domain layer*?!

b) And if when using TLA we decide to define *Infrastructure interfaces* in *Application layer*, then *Application layer* also isn't coupled to *Infrastructure layer*?!

c) Isn't with *Onion architecture* an \* Infrastructure layer\* coupled to Application Core ( which includes *Application layer* ), since *Infrastructure interfaces* are defined in *Application Core*?

d) If yes to **c)**, isn't it better to couple *Application layer* to *Infrastructure layer* ( for reasons I gave in my original question ( here I'm assuming Domain layer won't be calling Infrastructure services) )?

4)

From [Onion article](http://jeffreypalermo.com/blog/the-onion-architecture-part-1/):

> 
> The first layer around the Domain Model is typically where we would
> find interfaces that provide object saving and retrieving behavior,
> called repository interfaces.
> 
> 
> 

From [Onion article](http://jeffreypalermo.com/blog/the-onion-architecture-part-2/):

> 
> The controller only depends on interfaces, which are defined in the
> application core. Remember that all dependencies are toward the
> center.
> 
> 
> 

It appears the author is implying that since dependencies are only inwards and since Infrastructure interfaces are defined around Domain Model, that code within Domain Model shouldn't reference these interfaces. In other words, we shouldn't pass Repository reference as an argument to a method of a Domain entity ( which as you yourself has said is allowed ):

```
class Foo
{
           ...
       public int DoSomething(IRepository repo)
       {
              ...
            var info = repo.Get...;
              ...
       }
}

```

For reasons stated above I must confess that I fail to see the benefits of using *Onion architecture* or even how it is different from TLA ( assuming all *Infrastructure interfaces* are defined within *Domain layer* ) --> in other words, couldn't we depict TLA using *Onion architecture* diagram?!

**FINAL UPDATE:**

2)

b)

> 
> Yes. In TLA the domain layer would communicate directly with
> infrastructure in terms of classes declared by infrastructure layer
> not the other way around.
> 
> 
> 

Just to be sure – you're saying that with TLA an *Infrastructure interfaces* would be defined in *Infrastructure layer* ( I know that with Hexagonal/Onion architecture they are defined in Application core )?

d)

> 
> The coupling goes both ways. The application core depends on
> implementations in infrastructure and infrastructure depend on
> interfaces declared in application core.
> 
> 
> 

My point is that since with Onion architecture an ***InfServ** interface* is declared within *Application layer* ( here the assumption is that **InfServ** is never called by *Domain Layer* and as such we decide not to define ***InfServ** interface* within *Domain Layer* – see original **1a** question ), it means that *Application layer* controls the ***InfServ** interface*. But I'd argue that it would be better if *Infrastructure layer* controlled the ***InfServ** interface*, due to reasons stated in the original **2b** question?!

4)

> 
> 
> > 
> > It appears the author is implying that since dependencies are only inwards
> > and since Infrastructure interfaces are defined around Domain Model,
> > that code within Domain Model shouldn't reference these interfaces.
> > 
> > 
> > 
> 
> 
> In my opinion, your code sample is appropriate to code.
> 
> 
> 

So I was correct in saying that Onion Architecture doesn't "allow" *Domain Model* to reference *Infrastructure interfaces*, since they are defined in layer **InDe** ( **InDe** of course also resides within *application core* ) surrounding DM **strong text**and referencing them from **DM** would mean that dependencies go upwards from **DM** to **InDe**?

> 
> DDD is typically presented in a hexagonal/onion architectural style
> which is why there may be some confusion. I think what you've probably
> been doing is already hexagonal which is why it seems like it is the
> same thing.
> 
> 
> 

Yeah, I got that impression also. Though I do plan to look a bit deeper into the Hexagonal architecture ( especially since the new DDD book will base some examples on it ) after I finish reading Evan's book.

**FOURTH UPDATE:**

2)

d)

> 
> If infrastructure owned interface and implementation then the domain
> or application layer would be responsible for implementing persistence
> for itself.
> 
> 
> 

I assume *Application* or *Domain* layers would need to implement it for themselves because referencing interfaces defined in *Infrastructure layer* would Onion's rule of inner layers not having dependencies on outer layers ( *Infrastructure layer* being the outer layer )?

4)

> 
> Domain model can reference infrastructure interfaces, such as a
> repository, because they are declared together. If application layer
> is split from the domain, as it is in the Onion diagram, then the domain layer
> can avoid referencing interfaces because they can be defined in the
> application layer.
> 
> 
> 

But according to that article, *Infrastructure interfaces* are declared in a layer surrounding *Domain Layer*, which would mean it is closer to the outer edges of *application core* than *Domain Layer* – and as the article pointed out, the inner layer shouldn't have dependencies on outer layers>!

thank you