how to implement services and repositories on onion architecture?

Question

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.

1. 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;
           }
       }
       . . .
   }
   

2. What would be the problems of the above code? Should it use a domain service instead?

3. Should the domain services implementations be defined inside the core or at the infrastructure layer?

Answer 1

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.

Answer 2

What would be the problems of the above code? Should it use a domain service instead?

Two things to consider here:

1. 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).

2. 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).

Answer 3

1. How about

   private Lazy<City> _dCityLazy;
   
   public City DeliveryCity {
       get {
           return _dCityLazy.Value;
       }
   }
   

   where you'd inject the Lazy<City> by some mechanism?

2. You'd decide flexibly by injection from outside then in this example.

3. I'd say it really depends what a particular domain service does and where it is used.