Стиль Delphi: Как структурировать модули данных для кода, пригодного для модульного тестирования?

Мне нужен совет по структурированию программ Delphi для удобства сопровождения. Я пришел к программированию на Delphi через пару десятилетий в основном на C / C ++, хотя сначала я научился программировать на Turbo Pascal, так что я не испытываю дискомфорта с базовым языком. В моем предыдущем опыте работы с C ++ и C # я стал преобразователем TDD, используя cxxtest и NUnit.

Я унаследовал эту программу, за поддержку которой теперь отвечаю. Он состоит в основном из форм и пары модулей данных. Бизнес-логика приложения и доступ к данным в основном разбросаны по формам, а модули данных в основном являются просто местом для жизни глобальных объектов ADO. Доступ к базе данных обычно осуществляется путем обращения к глобальному экземпляру TADOQuery или TADOCommand, форматирования текста SQL прямо в соответствующее свойство объекта и вызова его метода Open или Execute.

Я пытаюсь передать бизнес-логику в степень инкапсуляции, где его можно тестировать. Я видел этот ответ , и он имеет смысл с точки зрения абстрагирования логики от форм. Мне интересно, каковы лучшие практики для доступа к данным. Я считаю, что модули данных должны предоставлять своего рода мини-API для конкретных приложений (вероятно, со всеми виртуальными методами), чтобы их можно было заменить имитирующими объектами для тестирования. Ссылка на , этот другой ответ показывает несколько примеров, которые заставляют меня поверить, что я на правильном пути, но мне все еще интересно увидеть какой-то документ с лучшими практиками в отношении модулей данных. На большинстве страниц, которые я могу найти через Google, представлены одни и те же примеры обо всех интересных вещах, которые вы можете делать во время разработки, с подключением элементов управления с привязкой к данным к запросам и тому подобному, что меня не очень интересует. на данный момент.