Практика «TaxiOrder»

Изучите пару классов TaxiOrder и TaxiApi — это модель предметной области по заказу такси.

TaxiOrder — типичная анемичная модель. Вся логика, связанная с этим классом находится в TaxiApi.

Переработайте класс TaxiOrder согласно принципам DDD. А именно:

• Сгруппируйте связанные свойства TaxiOrder во вспомогательные классы: PersonName, Address, Driver. Для этого можно как использовать уже готовые классы из пространства имён Domain, так и создавать собственные классы. При проверке этой задачи ValueType из предыдущей задачи будет доступен — используйте его! Где возможно замените использование отдельных свойств на использование новых классов.
• При подходе DDD работой с базой данных занимаются репозитории. Задача репозитория читать и записывать данные в БД и ничего более. В частности репозиторий водителей ничего недолжен знать про заказы. Переделайте репозиторий так, чтобы в нем остался только метод получения водителя и не осталось ссылок на заказы.
• Перенесите всю логику из методов TaxiApi в методы TaxiOrder. В TaxiApi должен остаться только тестовый код и вызовы соответствующих методов TaxiOrder.
• Добавьте проверки на валидность действий — кидайте InvalidOperationException, если действие в данном состоянии заказа невалидно.
• Замените все поля на свойства и закройте у свойств сеттеры. Впрочем, можно закрыть и сами свойства.

Проверяйте результат запуском тестов.

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