How should my team decide between 3-tier and 2-tier architectures? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 21 days ago.

Improve this question

My team is discussing the future direction we take our projects. Half the team believes in a pure 3-tier architecture while the other half favors a 2-tier architecture.

Project Assumptions:

1. Enterprise business applications
2. Business logic needed between user and database
3. Data validation necessary
4. Service-oriented (prefer RESTful services)
5. Multi-year maintenance plan
6. Support hundreds of users

3-tier Team Favors:

1. Persistant layer <==> Domain layer <==> UI layer
2. Service boundary between at least persistant layer and domain layer. Domain layer might have service boundary between it.
3. Translations between each layer (clean DTO separation)
4. Hand roll persistance unless we can find creative yet elegant automation

2-tier Team Favors:

1. Entity Framework + WCF Data Service layer <==> UI layer
2. Business logic kept in WCF Data Service interceptors
3. Minimal translation between layers - favor faster coding

So that's the high-level argument. What considerations should we take into account? What experiences have you had with either approach?

Answer 1

There's a time and place for up-front design, and it can only be made by an experienced architect who knows the ins and outs of your project. For me, if there is every any doubt or if it could go either way, I take it like this:

1. Start small (one layer)
2. Use interface-driven development & good SRP, agile design, etc
3. Once you have a working prototype, have a redesign session. The choice should be much clearer.

YMMV.

Answer 2

I don't believe the two sides are actually that far apart. Sounds to me like the 2 tier approach is looking with more focus on presentation and wanting the services to do the heavy lifting. The services will still likely have another tier involved for data access so it is another 3 tier'd approach. It is also the one we favor at my job because making the changes in the services often times doesn't require any changes to the consumers, assuming we maintain the same interface.

All that being said however, I think this should be far lower on the priority list of things to be concerned about. A tiered approach is not going to help you in and of itself. It is how those tiers are constructed that is important. I feel that it is far more important for everyone to agree on coding practices. Things like Dependency Injection, Separation of Concerns, Inversion of Control, Unit Testing, Mocking etc. These things are so much more important than being concerned with how many tiers there are. The tiers will follow naturally once these are in place.