I've been studying onion architecture for a couple of days. I understand that dependencies should always go toward the center and how to use dependency injection to accomplish this. But I have a couple of questions I still couldn't figure out.
Can a model (or entity) reference a repository interface or a service interface?
Eg: an Order
entity has a DeliveryCity
relationship established through Oder.DeliveryZip
property, which is not a foreign key, but is unique. To get the City for a zip, I must call ICityRepository.FindByZip(zip)
I have the following code in my model
class Order
{
. . .
[Inject]
public ICityRepository CityRepository { get; set; }
private City _dCity;
public City DeliveryCity {
get {
if (_dCity == null)
_dCity = this.CityRepository.FindByZip(this.DeliveryZip);
return _dCity;
}
}
. . .
}
What would be the problems of the above code? Should it use a domain service instead?
Should the domain services implementations be defined inside the core or at the infrastructure layer?
The repository is not a gateway to access Database. It is an abstraction that allow you to store and load domain objects from some form of persistence store. (Database, Cache or even plain Collection). It take or return the domain objects instead of its internal field, hence it is an object oriented interface.
Implementation of Onion Architecture First, you need to create the Asp.net Core web API project using visual studio. After creating the project, we will add our layer to the project. After adding all the layers our project structure will look like this.
Clean Architecture was introduced by Robert “Uncle Bob” Martin in 2012 in this post. It builds on the concepts of Onion Architecture but with somewhat different details of the layers. Instead of “Domain Model”, it refers to the core as “Entities”, but still representing enterprise-wide business rules.
According to Jeffrey Palermo: "The overall philosophy of the Onion Architecture is to keep your business logic and model in the middle (Core) of your application and push your dependencies as far outward as possible.
This is where Factories fit into the domain. An OrderFactory can take dependencies, such as a dependency on the IOrderRepository as well as a dependency on ICityRepository. When the factory is used to create (or reconstitute) an Order entity, the factory can lookup the City and set the Order property accordingly. Or, as herzmeister suggests, set it using Lazy so the lookup is only performed if/when needed.
What would be the problems of the above code? Should it use a domain service instead?
Two things to consider here:
ICityRepository
is not a real dependency for Order, in other words Order does not need it for its other methods. Real dependency is something that the object can not work without. So you may want to consider passing it as a parameter to the method like 'GetDeliveryCity
' (see this for details).
Finding city by zip code does not seem like a responsibility of the order. For Order to be cohesive it has to deal with order-related functionality only. You may want to take this functionality out of the order class.
Should the domain services implementations be defined inside the core or at the infrastructure layer?
Inside the core if this is truly domain service (not application service).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With