What's the best way to structure a project ?

Question

Hi,

I was wondering about how I should structured my projects.

We have some projects that are (re)use in other projects.

I mean, our data project and model project are use in one-to-many other projects.

What I really what to know is how to structure this type of project, what the best way to name it ?

In a standard 3-tier application, is should like something like :

1. DAL, DataAccessLayer, Data ...
2. Model, BusinessObject, BOL ...
3. UI, View, ...

Any other ideas ?

In each company I work, they got different way to organize it, is there one better than another ? Which one do you use and which one do you prefer and why ?

Thx!

Answer 1

Thats pretty much what i do, except ive got a couple of library projects where i try to put all my reusable code. Then my Model and DAL sit on top of these librarys, just adding project specifics to them

Answer 2

The software architecture depends on the type of software to build. If you want to do kernel programming other principles apply compared to doing application development. Yet another principles apply when your are going to do physical simulation, weather-forecast software, software IDE's or compilers.

I assume you want to do application developement. Well, then you will most probably want to design your software around the domain you are going to reflect. But even then there are lots of options.

For more insight in this big topic, I strongly suggest to read Domain Driven Design from Eric Evans and Applying Domain-Driven Design and Patterns from Jimmmy Nilsson.

Answer 3

For the data layer, I usually use:

Company.ProjectName.Data (i.e. AdventureWorks.OrderManager.Data)

For business layer I prefer something like "ObjectModel" (I have used "Business" or "BusinessLogic" but this is the area where data comes together in objects/classes so why not name it so?).

Company.ProjectName.ObjectModel (i.e. AdventureWorks.OrderManager.ObjectModel)

For UI, I like either plain old "UI" or "Presentation"...

Company.ProjectName.Presentation (i.e. AdventureWorks.OrderManager.Presentation)

Answer 4

I'm currently working on front-end web application that has a 3-tiered architecture:

• Client tier (the browser)
• Application tier (JEE application server, where the application will live)
• Backend tier (mainframe and legacy apps, various databases)

It has a layered architecture, and the layers in the Application tier are:

• Presentation layer: generates the UI that will be used in the Client tier
• Application layer: the equivalent of use cases, contains application logic
• Service layer: maps domain logic and data from Backend tier onto a Java model
• Integration layer: communicates with the Backend tier and contains gateways for JMS, email, ... and DAOs and other stuff

This is just an example project structure, and the end result will depend on the type of application. You can read more in my answer to this question on the division and naming strategy for packages.

You can add/swap/remove layers as you see fit. In a SOA for example, you can layer a Webservice layer on top of the Application layer or Service layer, so that the ESB (Enterprise Service Bus) can connect to your application or services. If any of this is impossible or seems very difficult, you don't have an optimal architecture and design.

When thinking about the structure of your project and to allow scenarios like the one above, some important properties of your modules and components you want are:

• Testability
• Reusability
• Maintainability

You can achieve this by designing for low coupling and high cohesion. Choosing a layered architecture by grouping modules by the level of functionality/abstraction is a good start. Within each layer grouping further by functionality helps as well. Letting each more specific layer only depend on interfaces of a more general layer reduces coupling too.