Comment planifier l'architecture pour une réécriture du système?

Question

Je prévois de réécrire un système actuel que j'ai précédemment travaillé sur une partie de. Je fais cela comme un exercice d'apprentissage. Voici une description de l'ancien système, de l'architecture de base du nouveau système, des meilleures pratiques que je veux suivre, des objectifs que je veux atteindre et de mes questions.

Permettez-moi d'expliquer l'ancien système:
1. Base de données SQL Server (non normalisé)
2. Palm Application (pour entrer des données dans la base de données)
3. Service Web 1 (Palm application envoie des données
4. Application Web (pour entrer des données dans la base de données) - J'ai créé ceci
5. Service Web 2 (Application Web 1 envoie des données à pour l'entrée dans la base de données) - J'ai créé ceci
6 Site Web (directement aux données CRUD et imprimer les rapports)

Permettez-moi d'expliquer mon concept d'architecture pour le nouveau système:
1. Web UI Solution d'application - remplace l'ancien site.
2. Solution d'application Web UI - Remplace l'ancienne application Web et l'application Palm.
3. Solution de services Web (en utilisant WCF) - remplace l'ancien service Web 1 et Service Web 2.
4. Solution Business Object - Objet d'affaires, le code appelle à Data Access Solution et code appelle Business Logic La solution sera placée ici.
5. Business Logic Solution - Les règles métier seront placées ici.
6. Solution d'accès aux données - Le code pour obtenir les données de/vers la base de données sera placé ici.
7. Solution d'objet de transfert de données - Utilisée pour transférer l'information comme suit: 7.1. Solutions d'interface utilisateur vers/à partir de la solution de service Web.
7.2. Solution de service Web vers/depuis la solution d'objet métier.
7.3. Solution d'objet métier vers/depuis la solution d'accès aux données.

Laissez-moi vous expliquer mes meilleurs concepts de pratique pour le nouveau système:
1. tests unitaires pour la solution de service Web.
2. Tests unitaires pour la solution d'objet métier.
3. Tests unitaires pour Business Logic.
4. Tests unitaires pour la solution d'accès aux données.
5. responsabilité unique Principe
6. Open/Close Principe
7. Liskov Remplacement Principe
8. Interface Ségrégation Principe
9. Dépendance inversion Principe

Nouveaux objectifs du système
Mon espoir est que je suis en mesure de générer un code propre qui a des tests unitaires enroulé autour de lui avec des tests d'intégration enroulé autour du système entier tout en apprenant les modèles de conception, WCF, TDD, Rhino Mocks, Expression Blend 3, Visual Studio 2010 et TFS 2010. Je voudrais également utiliser ce système comme référence pour l'apprentissage de nouvelles langues à l'avenir telles que Rails.

Questions
1. D'après ce que je layed dehors, quelqu'un at-il des problèmes avec mon architecture? De meilleures idées?
2. Y a-t-il certaines bonnes pratiques que je devrais suivre et qui ne sont pas listées?
3. Y a-t-il certaines bonnes pratiques que j'ai énumérées qui ne devraient pas être suivies?

Merci pour votre temps!

Answer 1

Eh bien, je ne sais rien de la taille de votre système, mais tout d'abord assurez-vous de ne pas courir dans le 2nd system effect.

Answer 2

Le but principal d'une architecture est de prendre en charge les exigences, donc je ne peux pas dire si votre architecture est bonne ou non sans connaître les exigences/cas d'utilisation dans cette instance spécifique. Cela dit, vous avez essentiellement décrit une application en couches à trois niveaux qui est généralement une approche sensée. Cependant, je ne l'aurais pas divisé en autant de solutions (j'aurais eu une interface utilisateur, des solutions de couche d'affaires et de données avec des projets distincts en leur sein). Je ne suis pas sûr de savoir pourquoi vous avez besoin de la "solution de transfert de données" - pourquoi avez-vous besoin d'une bibliothèque séparée pour gérer la transmission de données entre les couches? Ils devraient pouvoir appeler de l'un à l'autre dans la pile eux-mêmes.

Answer 3

tout d'abord je pense que votre approche est cool. Êtes-vous dans le temps et le budget? Le travail des gens d'affaires est probablement de vous dire: vous n'êtes pas. Maintenant, cela devient un peu plus sérieux: ce que vous devez faire est d'obtenir le système étape par étape plus propre, en termes d'architecture. Convice (j'espère que vous n'êtes pas seul) les membres de l'équipe que ces choses vont faciliter leur vie. Unittests écrit avant modifications, vous aidera à garder les exigences de l'entreprise ininterrompue. Votre plan est exellent mais je crains que vous ne pouvez pas l'atteindre avec un big bang! Cela arrive autant que je sache seulement 10^100 ans. Faites du bon travail!

Answer 4

Je trouverais un meilleur projet «d'apprentissage» (et plus réaliste): Utiliser le système et le refactoriser pour améliorer la qualité. C'est souvent une meilleure expérience d'apprentissage, car on part toujours de zéro. Je pense qu'être capable d'améliorer/refactoriser un système est une exigence quotidienne beaucoup plus commune des développeurs de logiciels en tant que projets greenfield.