Develop Reference

DDD paradigm. Is it possible to use a service from the Infrastructure layer on the Application Core.Domain layer

Sorry for my English, I am writing a real estate appraisal module and decided to try writing in the DDD paradigm.
I looked at examples and different articles and formed the following picture for myself (simplified):
ApplicationCore.Domain - the core of business logic, contains all the necessary objects divided into 2 typesа
Entitys - if an entity needs to be stored in a database and it is a ready-made complete business logic object.
ValueObjects - all other properties that encapsulate the behavior, are compared by the value of the fields, and are part of Entity
It is very important to create only valid objects, so I create everything through factories with a validator, and the constructors are private.
There should be no references to other dependencies, as isolated as possible.
ApplicationCore.App - a layer above ApplicationCore.Domain, contains a link to it.
works with objects from ApplicationCore.Domain and uses external services through Port/Adapter.
Port - For example, an abstraction of a repository, its implementation through an Adapter on the Infrastructure layer.
interaction logic for ApplicationCore is in AppServices - for classic implementation or in Command / Request - for CQRS
Infrastructure - contains a link to ApplicationCore.Domain and ApplicationCore.App.
Implements the ports of the ApplicationCore.App layer
Entities are independent from each other and refer to each other by keys for interaction.
I kept the basic logic of the assessment system in this paradigm.
But here it was necessary to add a service that receives additional information for evaluation from different sources, while in wiretapping mode.
Those. Works against the background of listening to TcpIp socket
Service settings are stored in the database and change frequently - i.e. you need to introduce a new Entity
A chain is formed
DataProvider (ApplicationCore.Domain) -> IDataProviderRepository (ApplicationCore.App) -> EfDataProviderRepository (Infrastructure).
DataProvider - must depend on ITcpIpTransport, without it it is just a set of settings for TcpIpTransport.
Logically, DataProvider is a service for receiving data, but it has settings and state stored in the database, i.e. you need to make it Entity.
If you make the DataProvider dependent on the Infrastructure layer, then ApplicationCore.Domain will also have ports to external services, is this permissible?
how best to implement it.

I've to admit that is a bit hard to understand everything. Especially at the end, you speak about object that isn't clear where they are and what they do.
Anyway, you cannot use anything for the layer above (infrastructure) into the layers below (application and domain). I don't know how would you do it, but as a simple dependency it would not leave you compile any project. You'll end with a circular dependency.
Given that you would not do this, you can build a service (I do it with static functions to avoid any kind of unwanted implementation) into the domain layer. That service use interfaces that are implemented into the application layer. Into the application layer you'll also use (or reuse) interfaces that will be implemented into the infrastructure layer.

Managing project references in an application which uses a DI container

I recently have read about the domain driven design. Finally, I came across the structure that my project should have. The structure would be like :
MyApp.Domain which contains entities and repositories interfaces.
MyApp.Domain.Services contains services.
MyApp.Infrastructure
MyApp.Persistence Contains the repositories implementation
MyApp.Application contains viewmodels and services
MyApp.Site
Right now, I just need to reference the MyApp.Domain and MyApp.Application to my site. On the other hand, if I want to use Unity as Ioc. The question is, Should I make reference to MyApp.Domain.Services and MyApp.Persistence as well? in order to register types?
Thanks

How else would Your "Application" know about Your business objects,
if You don't tell it, which assembly they're registered in ?
If You're looking for a more 'Plug-in' based approach, then it's a different story..
If speaking about plugins (not sure how Unity does that)
but the only way I got this to work (withing reasonable amount of effort)
was unit Autofac modules
You'd still need to have a place where You register your assemblies
and have something like a 'Filesystem watcher' that monitors a pat for new .dll's and loads them ect..

A common architecture when practicing DDD is the Onion Architecture. Mostly because it has several improvements over a typical n-tier architecture with barely any downsides.
It allows your domain and domain model to be at the heart of the software. The domain services layer would usually have a dependency on the persistence layer. In an Onion Architecture, this is flipped and the persistence layer holds the references to the domain services/model. To access the persistence layer, the interfaces for the key classes in the persistence layer are held in the domain layer and IoC is used to wire up the instantiation.

First of all, why have you created six different projects? They are just a fictionary separation. If you are the only developer, do you not trust yourself? If you are more than one developer, are your communication so bad that you can't agree on in which direction dependencies go?
Good separation comes from communication and talk within a team, and not because you have created multiple projects (adding a reference is really easy).
If you want to make sure that the code keeps good quality, introduce code reviews, measure the quality with the built in analytic tools or simply write unit tests.
Therefore, project references are not the problem and never have been. Add the reference in a way that makes it easy to run and maintain the application.
If you are serious about DDD forget about the project structure. It doesn't really matter that much. Understand the methodology and what's important in DDD. Buy the blue book by Eric Evans.

How To Implement IoC Containers in MVC Web Application with E.F

I am trying to wrap my head around IoC containers. As I delve deeper into this design pattern I come across multitudes of abstraction layers, interfaces and concrete classes when before I was simply instantiating a data-context class, using it and then disposing of it.
Whilst I am keen to continue forward there are some outstanding issues I don't know how to resolve and would like some clarification and guidance.
In a generic web application with 2 projects (mvc web & data layer
containing e.f.), if our dependancy resolver expects a repository
that implements a specific interface (allowing us to switch
repositories at any time in the future), where is this interface
defined? I dont see how it can be defined in the mvc web project because then the data access layer will become dependant on it and it cannot reside in the data access layer as then the mvc project depends on the dal and i've missed the whole point of this excercise. So is
the answer to define it in both projects and have each project
reference its own copy? ..Is that even possible? Or do i need to
create a third service layer project and stick one interface
declaration in it and have both projects reference this?
Ive seen a number of articles talking about Unity IoC with
interfaces such as IProductRepository, IClientRepository and
IProductService, IClientService (this is what I was referring to in
my opening paragraph). Am I correct in assuming that each of these
instances is supposed to reference a table in my database? If so
what happens if i have 50 tables? do i need to create 50 repository
interfaces and 50 table related interfaces just to decouple everything?
And how does using EF with POCO classes impact things? do i need to
have each POCO implement its own specified interface?
thanks

Ideally you would split your solution into several projects.
You would have a contracts project where your interfaces are defined, a dal where a concrete version of those interfaces are implemented.
Your mvc project would then reference the contracts project to handle the references to the types.
You would use an IOC container to scan the assemblies in the bin folder and find a concrete implementation of the dependencies for your controller. This means that you would build your dal into the bin folder of your mvc project. This means you can switch the dal out for other implementations simply by placing a new dll in the bin folder.
As for the repositories and tables, I tend to group them by business function. So a business function of managing users and their related tables would be in a user repository etc. but that is down to personal preference imo.

When you are breaking your project into tiers you are correct in not wanting your data layer to rely on a project further up the stack. In general you want these dependencies to be unidirectional. You can either continue what you are doing and put the interfaces in the data layer, or you can create a new project to house the model code, including the repository and service interfaces. Your data layer would depend on the model code, and your mvc layer will depend on the data layer.
To address your second question I would say this is where the art of design comes in. You don't necessarily want a one to one mapping between your entities and your data tables. If it makes sense and you believe it's manageable, especially with the help of Entity Framework, then go ahead with the one to one mapping. But keep in mind that the responsibilities of the persistence layer and the domain model layer are different. If the persistence layer starts to bog down your work creating the domain model then it's time to put some work into separating the two.
More important are the interface 'facades' that are going to be exposed to the mvc project. These are going to require some degree of decoupling from the model and persistence layers. They should be distilled down to the core responsibilities of the model. You don't want to clutter your application layer with the intricacies of your domain model.

Onion Architecture External Services

Im currently working on a project which is based on Onion Architecture . The above image Shows the Solution.
In the Infrastructure We have External Service . But the WebAPI has access only to Core .
But in the Web API project i want to access the some of the models exposed by the external services ?
How can we achieve this without adding reference to Infrastructure in the Web API .
Or we implemented Onion Architecture wrong?

conceptually you are on the right track, but the implementation isn't a hard a fast rule. to start you don't need 5+ projects at most you need 3 (web ui css/js/views, logic/controllers, code, and tests). and really you probably only need 2 (the application, the tests)
the idea of layers is conceptual, not physical. And there is not a hard and fast rule that says the layers must be completely segregated. rather the core focus of the application is what the application does. as you get into the details of how that is implemented you move to the outer layers.
in this instance you need to access data retrieved from an external service. create an abstraction for the external service IExternalServiceAdaptor. The interface may reside in the domain or server layer, but the implementation might reside in an infrastructure or outer layer where the details of how to call the external service are encapsulated within an implementation of IExternalServiceAdaptor.
If you stick with your physical separation you would have an interface in Core and the implementation in Infrstructure.

But in the Web API project i want to access the some of the models exposed by the external services ?
Actually, your WebApi project should only manipulate object defined in your Core project.
As Jason said, calls to any external services should be encapsulated within an implementation of an interface that resides in Core. And this is where models exposed by your external services will be mapped to your Core models.
Have a look at Matt Hidinger's source code on CodePlex here: http://onionarch.codeplex.com/ and check how he deals with this kind of problem, it's pretty straightforward and easy to understand.

WCF N-Tier Architecture

I'm working on a fairly straight forward multi-tier application (WPF, WCF, EF 4, and SQL). As far as architecture is concerned, we were planning to include a single "Common" project which will include both entities as well as service contracts.
Are there any advantages/disadvantages to having entities and service contracts in separate assemblies? Or is it usually good to keep them together?
I'm interested in hearing the opinion of others.
Thanks!

Having Contracts in a separate assembly gives you the advantage of the ability injecting to a different entities in a different assembly by providing the Contracts assembly to a developer , and he would implement it and give you a dll that you can put inside the project folder and inject to it using IoC framework like StructureMap without rebuilding,
having the contracts in the same assembly that contains the entities tie the contracts to the implementations...

If you are using a RESTful architecture with other .NET platform consumers - it's helpful to have the Service Contracts in a separate assembly (Shared) so that you can easily share your operation and data contracts with RESTful consumers without exposing any unnecessary data access components to your clients.
I would recommend that you keep the data access and service contracts isolated for this reason.

That is exactly how I structured the design for an e-commerce n-tier app I designed.
There are two common libraries - one for DTO's and another for interfaces.
Then the client and server included those librarues, and the service proxies were generated using common types.
The main advantage here is ease of compilation - you don't have to recreate the proxies when you change the insterface, the client and server are updated automatically.
I also had a utilities app that contained all the helper type stuff I needed.
EDIT: Sorry, just re-read your question. In my case, I had multiple interface libraries - one for the workflow library (with composed interfaces), and another for services (the thing being composed into workflow operations)
So in my case it made sense to keep them seperate.
If you only have one set of interfaces, and those interfaces all make use of your DTO's, there is no reason to seperate them into two libraries - one would be sufficient. Consider though if you may need to share your DTO's between more interface libraries in future, in that case rather keep the DTO's seperate from the interfaces from the start.