Designing the Architecture, separating projects. Am I "over thinking" ?

Question

Imagine having the following scenario:

You need to create a system where the Back end is seperate from the Front end, which is always important when programming, of course. But What if you want to be able to change the back end completely without changing the front end?

When creating a big website for instance, I'd go with the following projects:

Data - Handles all the data connections, the i.e. LINQ generated files and other partial overrides.

Interfaces - This layer is interesting, is this an overflow? Having the interfaces separated is because, the Business logic and the Data layer might have a lot of Interfaces in common and instead of Referencing the Data Layer from the Front, you can reference the Interface Layer and then have the Business Logic sending you an interface, instead of knowing about the correct classes and structure of the Data Objects in the Data Layer.

Business Logic - This speaks for itself, the business logic for the application.

Front End - Web, GUI or whatever is needed, code-wise of course.

My question is really, is this an overflow of layers and thinking? Is maybe the Interface Layer unimportant? Suggestions?

Answer 1

The interface layer is only a layer in the sense that you define it separately from everything else. An interface, however, should only define the boundary of a service, so it's not going to be full of code.

I can't see how you're going to pass an interface around without defining an interface-passing interface, which is overdoing it, I think.

Begin with a simple set of interfaces, if you want to go design-first, but be prepared to extend them if you find you haven't thought of every possibility up front.

So really, you have

• Data + Data interface
• Business logic + interface
• Frontend + Graphical user interface

Where each layer uses and encapsulates the previous, to some degree. There isn't really a separate layer for interfaces, or what would you put between the layers? Interface just means the boundary between two things, so use it as such.

It's very tempting to generalise and generalise, but then you just end up designing a new programming language, or paradigm. Most of the time, that's not part of the brief.

The brief! Of course, we forgot that. Start with that, determine your interfaces, and start coding the simplest use case. The thinking will develop as you go along.