Я думаю, что это могло бы иметь больше смысла, чтобы ответить на ваши вопросы в обратном порядке ...
Поскольку у вас есть API, то Facade Data Pattern может быть хорошей отправной точкой для начала. Цель этого шаблона - предоставить интерфейс, к которому могут подключаться внешние пользователи.
Этот тип структуры обычно требуется, если вы хотите выставить ряд функций (API) без разглашения того, как вы на самом деле о реализованных таких функциях. Так, например, вы просто показываете public BigDecimal calculateTax(BigDecimal amount, double percentage)
своим пользователям, не показывая, как вы шли и реализовали свой метод.
Наконец, это, как я хотел бы сделать это:
com.sample.myproject
будет мой основной проект и в нем я буду ставить какие-либо основные функции, такие, как сохранение объектов.
com.sample.myproject.api
будет по существу проектом с Interfaces
и другими вещами, которые я хочу разоблачить.
com.sample.myproject.impl
будет реализовывать два проекта выше, используя основной проект и некоторую дополнительную логику, чтобы выявить, какой уровень API доступен.
Исправьте меня, если я ошибаюсь. Если я хочу создать модуль API для моего приложения, имеющего уровень обслуживания, логики и доступа к данным. Только интерфейсы на уровне сервисов будут частью модуля API, так как это единственный слой, открытый клиенту. И интерфейсы, которые являются частью уровня логики и доступа к данным, останутся в модуле реализации. Я понял это правильно? –
@MeenaChaudhary: Уровень API также будет содержать любые объекты запроса/ответа, которые ваш API генерирует или требует. – npinti
Вы имеете в виду объекты переноса, которые используются служебным слоем в качестве объектов запроса или ответа? На данный момент мой объект переноса - это конкретные классы с методами getter/setter. Поэтому мне нужно было бы создать интерфейсы для моих объектов переноса и поместить их в модуль API и оставить конкретные реализации так, как они есть в текущем модуле? Это коррет? –