Как я должен планировать архитектуру для переписывания системы?

Question

Я планирую переписать текущую систему, над которой я ранее работал. Я делаю это как учебное упражнение. Ниже приведено описание старой системы, базовой архитектуры новой системы, некоторые рекомендации, которым я хочу следовать, цели, которые я хочу достичь, и мои вопросы.

Позвольте мне объяснить старую систему:
1. База данных SQL Server (не нормализована)
2. Palm Application (для ввода данных в базу)
3. Веб-сервис 1 (приложение Palm отправляет данные для ввода в базу данных)
4. Веб-приложение (для ввода данных в базу данных) - я создал это
5. Веб-сервис 2 (Веб-приложение 1 отправляет данные для ввода в базу данных) - я создал это
6. Веб-сайт (непосредственно для CRUD-данных и печати отчетов)

Позвольте мне объяснить мою концепцию архитектуры для новой системы:
1. UI Web Application Solution - заменяет старый веб-сайт.
2. UI Web Application Solution - заменяет старое веб-приложение и приложение Palm.
3. Решение для веб-службы (с использованием WCF) - заменяет старую веб-службу 1 и веб-службу 2.
4. Business Object Solution - здесь будут размещены бизнес-объекты, вызовы кода для Data Access Solution и вызовы кода для Business Logic Solution.
5. Business Logic Solution - здесь будут размещены бизнес-правила.
6. Решение для доступа к данным - здесь будет размещен код для получения данных в / из базы данных.
7. Data Transfer Object Solution - Используется для передачи информации следующим образом: 7.1. Решения для пользовательского интерфейса в / из Web Service Solution.
7.2. Решение для веб-служб в / из Business Object Solution.
7.3. Business Object Solution в / из Data Access Solution.

Позвольте мне объяснить мои концепции передового опыта для новой системы:
1. Модульные тесты для решения Web Service.
2. Модульные тесты для решения Business Object.
3. Модульные тесты для бизнес-логики.
4. Модульные тесты для решения доступа к данным.
5. Принцип единой ответственности
6. Принцип открытия / закрытия
7. Принцип замещения Лискова
8. Принцип разделения интерфейсов
9. Принцип обращения зависимости

Новые системные цели
Я надеюсь, что мне удастся сгенерировать чистый код, в который будут включены модульные тесты с интеграционными тестами, охватывающими всю систему, при изучении шаблонов проектирования, WCF, TDD, Rhino Mocks, Expression Blend 3, Visual Studio 2010 и TFS 2010. I также хотел бы использовать эту систему в качестве справочной для изучения новых языков в будущем, таких как Rails.

Вопросы
1. Исходя из того, что я выложил, у кого-нибудь есть проблемы с моей архитектурой? Есть идеи получше?
2. Существуют ли передовые практики, которым я должен следовать, которых нет в списке?
3. Существуют ли некоторые перечисленные мной передовые практики, которым не следует следовать?

Спасибо, что уделили время!

Answer 1

Ну, я ничего не знаю о размере вашей системы, но прежде всего убедитесь, что вы не столкнетесь с 2-ым системным эффектом .

Answer 2

Я бы нашел еще лучший «обучающийся» (и более реалистичный) проект: используйте систему и проведите ее рефакторинг, чтобы улучшить качество. Часто это лучший учебный опыт, так как всегда начинай с нуля.

Я думаю, что возможность улучшать / реорганизовывать систему является гораздо более обычной повседневной потребностью разработчика программного обеспечения, чем проекты «зеленого поля».

Answer 3

Прежде всего, я думаю, что ваш подход клёвый. У вас есть время и бюджет? Работа деловых людей, вероятно, заключается в том, чтобы сказать вам: вы не. Теперь это становится немного серьезнее: вам нужно сделать систему шаг за шагом более чистой, с точки зрения архитектуры. Консультируйте (я надеюсь, что вы не одиноки) членов команды, что эти вещи облегчат их жизнь. Юнит-тесты, написанные за до изменений, помогут вам не нарушать бизнес-требований. Ваш план превосходен, но я боюсь, что вы не сможете достичь его с большим взрывом! Это происходит, насколько я знаю, всего 10 ^ 100 лет. Сделай хорошую работу!

Answer 4

Основная цель архитектуры - поддерживать требования, поэтому я не могу сказать, хороша ли ваша архитектура, не зная требований / вариантов использования в данном конкретном случае.

Сказав это, вы в основном описали трехуровневое приложение, которое обычно является разумным подходом. Однако я бы не разбил его на так много решений (у меня были бы решения для пользовательского интерфейса, уровня бизнеса и данных с отдельными проектами внутри них).

Я не уверен, зачем вам «Решение по передаче данных» - зачем вам отдельная библиотека для обработки передачи данных между слоями? Они должны иметь возможность самостоятельно звонить из одного стека в другой.