2

We have multiple layered architecture

UI --> Application Layer --> Business Layer --> DB

There is a third party services that we are communicating with. If Business layer communicates to Third party service, then it has the advantage of making our Application layer light weight and at the same time there is data passing through an extra layer. Which layer Application or Business should communicate to that third party service and Why ?

4
  • I'd say you should fetch the data from a third party in the layer that needs it. There's no reason, in my opinion, not to do things in the place where they need to be done. – Mael Nov 21 '17 at 9:49
  • 1
    What exactly is the responsibility of the "Application Layer" in contrast to the "Business Layer" in your architecture? Are there different applications, and the BL is just for the "common business logic"? Is the AL responsible for controlling the UI, whilst the BL is "UI unaware"? Please clarify. – Doc Brown Nov 21 '17 at 16:10
  • 2
    -1, question still too unclear/vague after one day. Do not make us play guessing games, please. – Doc Brown Nov 22 '17 at 12:51
  • 1
    Voting to close... If you're trying to implement a well known pattern or architecture, we can help you understand it. Vague moralistic SE "should's" are subject to opinion, and "should" generally be met with, "it depends." – svidgen Nov 27 '17 at 5:06
3

The the-onion-architecture defines interfaces to external services in their domain-layer (you call it Busines-Layer) and the implementation of the service into a seperate service layer. This way busineslayer and other services can use all service-interfaces without depending on the service implementation.

your architecture will look like this:

 UI --> Application Layer --> Business Layer --> Service-Interfaces
 Service-Implementation --> Business Layer --> Service-Interfaces

i.e.

 WebOrder-Service-Implementation --> Order Business Layer --> Database Service-Interface

So to anwer your question:

> Which layer should communicate to third party?

Only the third-party-service-implementation and nobody else.

All other modules only communicate with the third-party-service-interface

3
  • This way busineslayer [sic] and other services can use all service-interfaces without depending on the service implementation. -- But it does depend on the service implementation. If the service changes, so must the implementation. – Robert Harvey Nov 22 '17 at 19:57
  • @RobertHarvey Even if the service changes, it still must fulfill the needs of the business layer as defined by the interface. The business layer owns the interface, not the service. – Daniel T. Nov 27 '17 at 2:47
  • 1
    Oh, so what you really mean is that the client doesn't have to depend on (or care about) the implementation details, so long as the contract is still satisfied by the implementation. – Robert Harvey Nov 27 '17 at 3:02
1

Easy to answer:

If communication with third party is application specific (usecase specific) put it in the application layer.

If communication with third party is independent from the current application and communication should take place everytime the domain layer is called put it in the domain layer (business layer).

I further suggest to wrap third party code. So you only depend on your own code.

1

Your db layer should be called infrastructure (data) layer. This layer should be in charge for repositories such as db. Since third party is nothing buth a remote repository that can be used accross your application layer i would definitelly put it inside infrasyructure layer. Should you want to replace third party provider you replace it in infra layer without hurting the rest of your app. I believe it is called persistence ignorance

0

Does the business layer require information from the third party in order to work properly? I'm assuming so. So the question is whether the application layer should retrieve the data and pass it to the business layer or if the business layer should simply retrieve it itself.

My thoughts are that while the database layer should never retrieve anything that isn't from the database (with possible exception of the connection), the business layer isn't restricted in this sense. If the business layer needs the information provided by the third party and the application layer doesn't need it, it makes no sense for the application layer to simply pass it.

On the other hand, if application layer and business layer both need the info (and you would be wise to ensure that that's correct behavior), the application layer should load it and pass it on to the business layer as necessary. Otherwise, let the business layer make its own calls to the third party services.

0

In our architecture, we view services as repositories, making them peers to other components in the data layer. The business layer is responsible for retrieving necessary data and acting on it. It calls down into the repositories (or services) to get what it needs, and returns any results to the calling application tier methods.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.