Hi.

Can anyone give me some advice on designing a layered architecture for a software project i am working on?

since i always develop my programs in modules they come out in some form of layered architechture but this is always by accident. i want to develop it layered from the start.

i have thought of the following layers. database access layer, screen layer, processing the data from the database layer, do calculations and deal with the user layer.

these layers should explain themselves. i would appreciate it if someone can tell me if this is good or whether i should put in more or fewer layers or whether i have to change the layers. basically is there some template or blueprint from which a good layered architecture can be derived.

I would also appreciate it if someone could point me to good web sites which deals with this.

Thank you.

Draw diagrams - UML seems to be the thing to use nowadays.

There are some good tools (and some free ones) which help with the maintenance. Though if you're only planning a few diagrams, paper and/or a whiteboard with post-it notes makes a great substitute.

Although UML has 13 different diagram types, some of them are rather specialised. Don't feel too weird if you can't think of a good reason to use them. UML aims to span from designing the garden shed to designing a skyscraper. There's just some stuff you don't need at the lower end of the scale.

Roughly speaking, you start with a single box representing your entire system, and you surround it with all the interactions with the outside world. Say, users, sensors, display devices, remote machines etc etc.

You then break your system into between 4 and 6 sub-components representing the "big" ideas within your program. These will interact with the outside world (see your first diagram) and will create new interactions between the entities you created.

Keep doing that until you start to create very small components which seem trivial to implement in code.

Oh, and before you rush to start coding, walk the diagrams through with someone (anyone) just to make sure it all hangs together properly. A quick diagram fiddle may represent a saving of several weeks of coding effort.

thanks salem. it does not exactly answer the question i asked but it is usefull non the less.

it touches upon a subject which i have thought of often. so far i have created smaller systems and i spend very little time designing before i start to code. but my current project is much bigger and i am going to follow your directions when i design it.

and i suppose that sooner or later i am going to have to learn UML. actually i have a C++ textbook which explains it in detail. but love to make the excuse of not enough time so i have only glanced at it so far.

you layers is nice you don't need more!
any basic business project should have UI Layer, Business Logic Layer, and Data Access Layer.

what about if you need security on all the layers?

you should add layer cross cut on your layers (AOP)

what about you areee using Distrbutied database?

you should add after Data Access Layer a Layer called Communication Layer.

I think your architecture seems to be good you don't need more layers

Creating "layers" only really makes sense if you plan to create several different projects with a shared theme. In other words, the extra effort you put into say your "display" layer to make it generally more useful (over and above what is strictly necessary for a given project) needs to have some payback down the line in making future projects a lot easier.

The problem is, unless you're exceedingly familiar with the solution domain (you've done the same thing several times already, and you're getting bored with it), is coming up with the API for your layer which is useful to you.

The danger is that the API will bloat, will have an ad-hoc interface and will suck in resources just to maintain itself rather than being in any kind of "finished" state where you can make use of it.

>...several different topics with a sgared theme..

yes that is exactly what this is. it is going to be three projects. that is what promted me to go for the layered architecture in the first place.

one more thing salem. are you saying that a layered architecture is more difficult or troublesome for very little reward other then multiple projects?

i have only read one book on layered architecture some years back when i was in tech. i cant remember that much of the book and at the time i did not take much note but the book was full of praise for layered architecture.

it said that it makes both debugging and maintenance easier. apparently the extra effort one spends before starting to design the detailed solution soon repays itself.

> it said that it makes both debugging and maintenance easier.
So does working from a nice design with well defined functions and interfaces.

> are you saying that a layered architecture is more difficult or troublesome
> for very little reward other then multiple projects?
Not at all. Sometimes a few simple decisions can have an immediate and huge payoff. The danger is getting sucked into the "must have layers" mentality and spending way too much time creating something which isn't all that useful. If you can see a layer and how to use it then fine, but don't spend the time trying to force it.

Also, continually review progress as you go, as things do become clearer later on (like spotting a new opportunity for a new or better layer).

>must have layers mentality
>dont spend time trying to force it

i hear you.

An interesting summary of layered architecture is in Eric Evans' "Domain-Driven Design Quickly" starting on p. 29. It describes four layers -- UI (presentation), Application, Domain (business logic) and Infrastructure.

It's a mini-book PDF file you can download from http://www.infoq.com/minibooks/domai...design-quickly

@salem or anyone else that gets his point
>>start with a single box taht represents the entire system. etc etc.

i am only now beginning to appreciate the value of this reply and the next one is very usefull too. especiallyin addition to what infarctation, i think, said about the value of object orientated becomming obvious once you start working on bigger projects.

can you suggest any good books which center on this very method that you suggest here.

i am not as such talking about uml, although it is no problem if it is included in the book. rather i am talking about the steps which say that i must start with a single box which represents the entire system and from there divide the system etc. if it could be about object oriented then it would be even better.