Basic Architectures

I'm a firm believer that "simplicity is the ultimate sophistication" (Leonardo Da Vinci).
A reusable, simple and clear architecture can help tremendously coding any kind of software. I'm not talking Enterprise Architecture here, just basic code/project structure convention.
It's nothing new, although not every developer knows about it nor its benefits.

Project Architecture

At Tripfilms we decided to go with the "1 project, 1 purpose" approach. There many ways to implement a given purpose, and thus we group those under 1 (usually Eclipse) project.
With Java, we follow the Maven "way of doing things" (file structure, dependency management, development lifecycle, etc.)

Here are three types of projects we often experience.

Core Projects

A Core project provides the materials and the tools to build a product. It's always the invisible part of the product (people never saw the hammer or the nail gun construction workers used to build up one's house, right?).
Most of the time it's the project dealing with the database of a customer.

Front-End Projects

A Front-End project (e.g. web or GUI) is the visible part of the product (like a finished house). It usually relies heavily on at least the core project(s) to deal with data and present it to the user to interact with it.

Third Party Clients

When we can't find the SDK for say a (somewhat complicated) web service, we're force to create it ourselves, the goal being to abstract all the logic to deal with the web service from the rest.
We usually follow a Core project architecture here but we make sure we don't soil it with business logic from the product we're building. This project must be "pure".
Another project will be created to bridge the product needs to this service.
Below is a sample diagram where tripfilms-travelocity-core is the bridge between tripfilms-core and travelocity-sdk. The front-end project can then use both tripfilms-core and tripfilms-travelocity-core to implement user interactions.

Third Party Project Architecture

Benefits

Having a convention in the structure of projects helps new comers jump right in and find things easily, whether it's for troubleshooting or implementing new features.
In the Java world, Maven is becoming more and more a recognized (almost standard) way of developing software. Maven recommends some project structure that most Java developers find intuitive (NB: I did not say Maven is intuitive, just the file system).
It's not unusual to see developers mingling Core and Front-End (especially in the Ruby world). In my experience, it's easier to deal with the two separately, since each has its own specific needs (e.g. I'm not gonna test one the same exact way I test the other one). Moreover, Core becomes more reusable from the get go.

Code Architecture

It consists of 3 layers:

1. the domain model (what we call Business Entity), 
2. the service layer (what we call Business Object) 
3. and the data layer (what we call Data Access Object). 

This architecture follows the separation of concern practice.
We use a different namespace/package for each layer. For example we have com.tripfilms.core.be, com.tripfilms.core.bo and com.tripfilms.core.dao packages in our Tripfilms.com Core project.
We use BE-BO-DAO as our architecture for Core projects. For Front-End projects we go with Form-Views-Controller (the old MVC indeed).

Business Entity (aka BE)

Our entities are bare metal Java beans: they MUST have no logic whatsoever. They are pure data containers (class members and that's about it!).
The only exception we've been introducing lately is the use of annotations (Java) to map class members to table columns or document fields from the persistence medium.

Data Access Object (aka DAO)

It's nothing new for Spring Framework users. It's the layer that deals with data, whether it comes from an RDBMS, a document storage, a key-value storage, etc. It will communicate with the storage and populate BEs for Business Object to use and implement business rules/logic.

Business Object (aka BO)

In the Spring Framework realm, it's usually called a Service (and before a Component?). I tend to disagree with the use of this term as I feel a Service can use many BOs for example. Like if you order food through room service in a hotel, the person bringing food is (usually) not the same one who cooked it.
I'm not a big fan of "Object" in Business Object either: Microsoft uses the term Business Component. I like it, but BC didn't sound as good as BO ;)

Form (Front-End)

Forms represent the BEs but more Front-End specific.
For example, a registration form will contain a "RePassword" field to check against the "Password" field to make sure the user entered what she intended to, whereas the Registration BE is unlikely to contain that "RePassword" member in it.

Controller (Front-End)

Controllers bridge the business logic (BO) to the front end.
For example, some business logic might require a meaningful amount of data to collect from a user. Instead of overwhelming the user with a 5 screen long form, a wizard flow might be implemented in the controller (i.e. multiple pages/screens to collect the data).

Benefits

The BE layer having no logic or interaction whatsoever, it doesn't need any special attention or care (i.e. no unit tests).
We're then left with the 2 layers: DAO and BO.
Layers are good because, among other things, it means you can mock one to test the other. In the case of the BO layer, you mock DAOs to unit test the business logic.
For the DAO layer, it's usually better to go with integration tests to make sure everything is working properly, before going any further. If the DAO is dealing with a web service without a sandbox, it's preferable to mock up that web service.
Since each layer has a purpose, it also helps when troubleshooting or implementing new features: developers don't waste time figuring out where to look for, add or update code.

Resources

[1] http://msdn.microsoft.com/en-us/library/ee658103.aspx
[2] http://msdn.microsoft.com/en-us/library/ee658109
[3] http://msdn.microsoft.com/en-us/library/ee658102