Architecturedesignjava
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 ?
The strategy I've used when there are several initialization parameters is to create a type which just contains the parameters for initialization
public class DataTypeTwoParameters {
public String foo; // use getters/setters instead if it's appropriate
public int bar;
public double baz;
public String quuz;
}
Then the constructor for DataTypeTwo takes a DataTypeTwoParameters object, and DataTypeTwo is constructed via:
DataTypeTwoParameters p = new DataTypeTwoParameters();
p.foo = "Hello";
p.bar = 4;
p.baz = 3;
p.quuz = "World";
DataTypeTwo dtt = new DataTypeTwo(p);
This gives a lot of opportunity to make it clear what all the parameters going into DataTypeTwo are and what they mean. You can also provide sensible defaults in the DataTypeTwoParameters constructor so that only values which need to be set can be done so in any order the consumer of the API likes.
It sounds like you're describing the onion architecture, a form of n-tier architecture -- which is just a fancy way of saying it has components broken out into layers.
The layer you're focusing on is the Infrastructure layer. Data is the most common component of infrastructure. But other functions can be contained in separate libraries in the same layer.
Architecture is a subjective thing. The best I can do is offer you how I would set up the project.
If you want to be really explicit about your layers, you can use solution folders to separate things out.
Notice I didn't include the solution folder in the namespace -- it's Whatever.Web, not Whatever.Client.Web. That's another subjective call, but I've found it cleaner this way. Solution folders aren't mandated to be part of the namespace like project folders are.
And in the end, once I had an intuition for what concerns belong in which layer, I found I didn't even really need the solution folders:
Just by glancing at that, it's clear to me that the shared models are in the Core, the client is the Web, and everything else is there to support as infrastructure. But if I started getting many more projects in each layer, then I could switch back to organizing with solution folders.
For extra credit, I might mention that personally my Core/Domain layer would have interfaces for the Infrastructure services:
And the infrastructure library would then implement that interface, so you can always 'swap out' the dependency, to whatever other library implementation.
Best Answer
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:
i.e.
So to anwer your question:
Only the third-party-service-implementation and nobody else.
All other modules only communicate with the third-party-service-interface