How should I plan the architecture for a system rewrite?

Question

I am planning to rewrite a current system that I previously worked on a portion of. I am doing this as a learning exercise. Below is a description of the old system, basic architecture of the new system, some best practices I want to follow, the goals I want to acheive and my questions.

Let me explain the old system:
1. SQL Server Database (not normalized)
2. Palm Application (to enter data into the database)
3. Web Service 1 (Palm Application sends data to for entry into database)
4. Web Application (to enter data into the database) - I created this
5. Web service 2 (Web Application 1 sends data to for entry into database) - I created this
6. Website (to CRUD data directly and print reports)

Let me explain my architecture concept for the new system:
1. UI Web Application Solution - Replaces the old Website.
2. UI Web Application Solution - Replaces the old Web Application and Palm Application.
3. Web Service Solution (using WCF) - Replaces the old Web Service 1 and Web Service 2.
4. Business Object Solution - Business object, code calls to Data Access Solution and code calls to Business Logic Solution will be placed here.
5. Business Logic Solution - Business rules will be placed here.
6. Data Access Solution - Code to get data to/from database will be placed here.
7. Data Transfer Object Solution - Used to transfer information as follows: 7.1. UI Solutions to/from Web Service Solution.
7.2. Web Service Solution to/from Business Object Solution.
7.3. Business Object Solution to/from Data Access Solution.

Let me explain my best practice concepts for the new system:
1. Unit tests for Web Service Solution.
2. Unit tests for the Business Object Solution.
3. Unit tests for the Business Logic.
4. Unit tests for the Data Access Solution.
5. Single Responsibility Principle
6. Open/Close Principle
7. Liskov Substitution Principle
8. Interface Segregation Principle
9. Dependancy Inversion Principle

New system goals
My hope is that I am able to generate clean code that has unit tests wrapped around it with integration tests wrapped around the whole system while learning design patterns, WCF, TDD, Rhino Mocks, Expression Blend 3, Visual Studio 2010 and TFS 2010. I would also like to use this system as a reference for learning new languages in the future such as Rails.

Questions
1.Based on what I have layed out, does anyone have issues with my architecture? Any better ideas?
2.Are there certain best practices I should be following that are not listed?
3.Are there certain best practices I listed that should not be followed?

Thank you for you time!

Answer 1

Well, I don't know anything about the size of your system, but first of all make sure you do not run into the 2nd system effect.

Answer 2

An architecture's primary purpose is to support the requirements, so I cannot say whether your architecture is good or not without knowing the requirements/use cases in this specific instance.

Having said that, you've basically described a 3-tier layered application which is usually a sensible approach. However, I wouldn't have broken it into so many solutions (I'd have had a UI, Business and Data layer solutions with separate projects within them).

I'm not sure why you need the "Data transfer solution" - why do you need a separate library to handle passing data between layers? They should be able to call from one to another down the stack themselves.

Answer 3

first of all I think your approach is cool. Are you in time and budget? The buisness peoples job is probably to tell you: your are'nt. Now it becomes a little bit more serious: What you need to do is to get the system step by step cleaner, in terms of architecture. Convice (i hope you're not alone) the team members that these things will ease their life. Unittests written before changes, will help you to keep business requirements unbroken. Your plan is exellent but I fear you cannot reach it with a big bang! This happens as far as i know only 10^100 years. Do a good job!

Answer 4

I would find an even better 'learning' (and more realistic) project: Use the system and refactor it so the quality is improved. It is often a better learning experience as always start from scratch.

I think being able to improve/refactor a system is a much more common daily software-developer's requirement as green-field projects.