3

Consider a web-application with a repository layer (persistence), a service layer (application) and a web (UI) layer.

Consider a component (i.e. ExternalProgramExecutor) which is not a UI component and does not depend or any component from the service or the repository layers.

The question are:

  • Does this component belong to the service layer?
  • Does this component belongs to the persistence layer?
  • Should it be treated separately from those layers? If so, what is the name for this part of the architecture?
Igor Mukhin
  • 15,014
  • 18
  • 52
  • 61

9 Answers9

4

Ask yourself the following questions:

  • Is it persisting something?
  • Is it providing a service?
  • Are these things it is doing specifically relevant to your application?

The answer to the first question should be no, since you already told us that the component is not hooked to the application in any way.

The answer to the second question should be yes, since that's what all good software components provide: some sort of service.

But any flexible component worth its salt ought to work well just about anywhere in a software application, so the real question is this: where should you put the component such that your web architecture is most faithfully preserved?

Web architecture is just an organizational mechanism, after all. If you're trying to find the answer in The One True Web Architecture Reference™, you're doing it wrong.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
1

Personally I would add another question to the list of questions @Robert asked:

  1. Is it totally independent of my application?

For me I usually add a new Utility/Framework component in my architecture, which is where I put totally independent components that can be reused in other applications later on.

Tamim Al Manaseer
  • 3,554
  • 3
  • 24
  • 33
1

According to DDD, this kind of service - that seems to be assimilable to "Util/Helper" services - should be in the "Infrastructure Layer" (src: InfoQ)

Architecture

A typical enterprise application architecture consists of the following four conceptual layers:

  • User Interface (Presentation Layer): Responsible for presenting information to the user and interpreting user commands.
  • Application Layer: This layer coordinates the application activity. It doesn't contain any business logic. It does not hold the state of business objects, but it can hold the state of an application task's progress.
  • Domain Layer: This layer contains information about the business domain. The state of business objects is held here. Persistence of the business objects and possibly their state is delegated to the infrastructure layer.
  • Infrastructure Layer: This layer acts as a supporting library for all the other layers. It provides communication between layers, implements persistence for business objects, contains supporting libraries for the user interface layer, etc.
Jérémy Buget
  • 168
  • 2
  • 11
0

I hope it would be part of "Infrastructure Layer". Please have a look on:

http://en.wikipedia.org/wiki/Common_layers_in_an_information_system_logical_architecture

http://www.bennadel.com/blog/2385-Application-Services-vs-Infrastructure-Services-vs-Domain-Services.htm

Thanks.

Praveen Prajapati
  • 969
  • 1
  • 16
  • 21
0

Given the constraints of your question, I would ask what the purpose of your independent component is? Is it primarily a facade around some data (which would make it part of your persistence layer), or is it part of the domain or business logic or workflow of the application (your application layer)? Something like an external task executor, I would tend to think would be a part of your application layer.

aet
  • 7,192
  • 3
  • 27
  • 25
0

Conceptually, 'ExternalProgramExecutor' looks like a service so it belongs to the service layer.

To go in the details of the service layer, there is two possibilities :

  1. The service 'ExternalProgramExecutor' has the same nature as the other services, so it's another 'bullet point' of the service layer,
  2. The service is deeply different from others, it's another 'block' of the service layer.

This disjunction stays with a more pragmatical point of view (implementation) :

  1. The service relies on the same features (same UI, same access to persistence) : it should be integrated with the other parts of the service layer, to use their API...
  2. The service is inherently standalone: that's a chance, don't create unnecessary dependencies, develop it independently.
jacquarg
  • 176
  • 1
  • 7
0

I tend to view services as interfaces over your domain models, and since it sounds like that relationship doesn't exist, it doesn't sound like a service in that sense.

Your persistence layer mediates communication with your data store, but it sounds like this component doesn't have much to do there either.

So what layer does it belong to? Does it really need to belong to one? By asking these sorts of questions, it sounds like you're already taking the time to organize your objects properly. If you have a single extraneous component, you could either:

A) drop it into the layer where it is used the most

B) drop it into its own assembly and stop worrying about labeling it :)

Mister Epic
  • 16,295
  • 13
  • 76
  • 147
0

A multi layered (software) architecture is using different layers for allocating the responsibilities of an application, so we have:

  1. Separation of responsibilities.
  2. Easy to see workflow.
  3. Ability to replace layers implementation with minimum effort-side effects.

From point 3, if changing "ExternalProgramExecutor" does not require any change on other layers. I guess that deserves a layer for itself. I used a layer called "Ext" on a project with similar purpose.

If the change requires any change add it to the layer which needs modifications.

Hope it helps.

victoriza
  • 426
  • 4
  • 8
0

Well, ExternalProgramExecutor is a service on its own since your application makes use of this as an external component.

Obviously, you cannot put that service into your application if you are not going to put the source code of that component as part of your application's project. Therefore, you are in fact going to have a Gateway over that service/component in your project. In order to make it SOLID, your gateway will be abstract, and your question is where you should reference that abstract gateway from.

Answer completely depends on what kind of functionality is provided by the ExternalProgramExecutor (and therefore by the Gateway) and how your project is using that functionality. Go from top to bottom layers (DAL -> ... -> UI) of your application while the abstract functionality is not part of the layer. Once you found the right layer, use the gateway in that layer, and bottom layers should not be aware of the concrete gateway existence at run-time.

Tengiz
  • 8,011
  • 30
  • 39