I am studying Onion Architeture but i got some doubts:

All the samples (github) I found over internet are too simple, or are implemented under DDD (which I have not studied at the moment) so I can not get a clear concept.

About Domain.Services I have some doubts:

  1. It has to define implementations? For all Services interfaces declared?
  2. It has to define domain logic, can you give a detailed example? (avoid tipical GetUser() example ). I can imagine this service as for example

     public interface IMarketKartService  
        double AddItemToKart(Kart kart, ShopItem item);  
        double CalculateBill(Kart kart); 
  3. This layer is able to use repositories or not?

Later is Application.Services layer. As i read it should be an API, and implement user cases that get consumed by the User (for example from a WinForms app)

  1. Am I right?
  2. Is this layer able to use repositories? (I suposse that yes but please clarify) So repositories in which layers are eligible to use?

I don't get the sense of many DDD terms, so please avoid them in your explanations.

  • 1
    Maybe (correct me if I'm wrong) you have a misconception here: with Onion you do not have insulated layers. Application may (and should) access domain model and you do not duplicate in service layer what you already have in the domain (to answer #2). About #3 and #5: each outer layer can use ANY inner layer (not only the immediate one). This should also answer to #1: unless specific implementation requirements impose otherwise then yes. In this layer you expose interfaces and it contains also their implementations (ADDING on the top of the domain, do not replacing it). Aug 8 '18 at 11:52
  • 1
    About my last sentence: well...of course there are corner cases. For example a service may expose an interface tuned for network operations (which is obviously different because of network latency and response time then you have to optimize the number of requests). In this case some level of duplication is unavoidable. Aug 8 '18 at 11:55
  • 1
    Your service layer SHOULD have implementations (otherwise...where implementation is defined? If it's implemented directly in domain model then caller MUST access directly the domain model). Let me repeat: unless you're making an optimized service to optimize network requests then UI (for example) can access domain, no need to wrap each layer. About repos: yes, repository returns domain objects then it can be well accessed from services. Just do not make the mistake to create a service layer which just forward all calls to repository: it's useless and unnecessary. This is where Onion differs. Aug 8 '18 at 12:12
  • 1
    Domain model should...describe the domain. For example in a typical LOB on-line shopping you will have Cart, Product, Order and so on. All the business logic says there. What's a service for? 1) To simplify use-cases: when placing an Order you may want to perform other operations (for example to check if product is currently available and if not then order one) or - probably - 2) interact with external services (for example calling the payment processing provider for pre-authorization. Aug 8 '18 at 12:19
  • 1
    As a general rule of thumb (for me) when I have to interact with anything else but the domain model then I need a service. Note that I (maybe wrongly?) put TWO kind of services in the service layer: use-cases (you may call it Facade) and services which abstract external services (which do not belong to my domain model like payment processing provider in the previous example). I put facades in the service layer because it's also the place I put services which access domain model with a different interface (again...for example when I want a coarser interface to optimize network access) Aug 8 '18 at 12:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.