Можно ли создать модель домена для унаследованного кода без рефакторинга?

Question

В настоящее время у меня есть клиент, который хочет, чтобы я «абстрагировал» модель предметной области от существующего кода, но они специально сказали, что я не должен реорганизовывать сам существующий код. Мой вопрос: 1) целесообразно ли это и 2) какие методы вы бы применили в этом сценарии, если вы не можете реорганизовать код, но они ожидают, что вы придумали для него модель?

(РЕДАКТИРОВАТЬ: я не могу понять, как это сделать, но каким-то образом неспособность провести рефакторинг в этом случае просто кажется неправильным. Кто-нибудь еще сталкивался с таким сценарием?)

Answer 1

Это звучит для меня почти невозможно достичь.

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

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

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

Для этого вам нужно всего лишь изменить то, как классы являются ссылками, а не изменить существующий код. Однако у вас не было бы модели домена ... у вас была бы одна сборка такого рода, в которой была бы логика домена.

Введение правильной и полезной модели предметной области невозможно без рефакторинга. Весь смысл процесса состоит в том, чтобы идентифицировать фактические бизнес-объекты, которые вы выражаете, а затем отразить эти объекты в модели предметной области. Это потребует введения новых классов, извлечения методов, работы с абстракциями. (Это просто начало процесса)

---

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

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

• Приложение Мартина Фаулера Strangler

Идея заключается в том, что вы создаете новое приложение поверх существующего приложения, очень похожего на лозу, медленно окружая, а затем уничтожая части исходного приложения по мере их замены.

Это очень намеренно медленный процесс, снижающий риск и делающий понятным постепенный отказ от устаревшей системы.

• Антикоррупционный слой (из книги DDD)

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