Меня попросили создать мини-приложение с использованием гексагональной архитектуры для внешнего приложения с использованием API для отдыха. И у меня возникла большая дилемма.
Чтобы использовать подход портов и адаптеров, я создал эту структуру папок.
adapters = `fetching the data`
application = `hooks to store the data`
domain = `logic to filter the data for the hooks`
presentation = `the rendering of the data`
Проблема в том, что ответ API iTunes возвращает около 15 свойств, а мне нужно только около 4, поэтому у меня возникает соблазн фильтровать на уровне адаптера, чтобы получить только то, что мне нужно. Но я чувствую, что нарушу принципы архитектуры.
Что дает? Сделаю ли я что-то хорошее с точки зрения производительности, используя предварительную фильтрацию?
Адаптер сырой
export async function fetchTopPodcasts() {
const endpoint =
'https://itunes.apple.com/us/rss/toppodcasts/limit=100/genre=1310/json';
const proxy = `https://api.allorigins.win/get?url=${encodeURIComponent(
endpoint,
)}`;
try {
const response = await fetch(proxy);
if (!response.ok) {
throw new Error('Network response was not ok');
}
const data = await response.json();
const podcasts = JSON.parse(data.contents);
return podcasts.feed.entry;
} catch (error) {
console.error('Fetch error:', error);
throw error;
}
}
Адаптер отфильтрован
export async function fetchTopPodcasts() {
const endpoint =
'https://itunes.apple.com/us/rss/toppodcasts/limit=100/genre=1310/json';
const proxy = `https://api.allorigins.win/get?url=${encodeURIComponent(
endpoint,
)}`;
try {
const response = await fetch(proxy);
if (!response.ok) {
throw new Error('Network response was not ok');
}
const data = await response.json();
const podcasts = JSON.parse(data.contents).feed.entry;
// Filter the necessary data
return podcasts.map(podcast => ({
id: podcast.id.attributes['im:id'],
name: podcast['im:name'].label,
image: podcast['im:image'][2].label,
author: podcast['im:artist'].label,
}));
} catch (error) {
console.error('Fetch error:', error);
throw error;
}
}
Помните, что бизнес-уровни (ядро/домен) не должны знать об уровне инфраструктуры (потому что в противном случае вы не сможете поменять местами адаптеры, нарушая шестиугольные принципы).
Таким образом, ваш вариант использования не должен знать модель объекта iTunes. Ответ на ваш вопрос — отфильтровать то, что вам не нужно на уровне адаптера. Таким образом, вы можете заменить адаптер iTunes на другого поставщика, например Spotify, без необходимости менять бизнес-уровень. Для этого на бизнес-уровне должно быть описание того, что такое подкаст.
Это также полезно для тестирования, поскольку теперь вы можете передать тестовый дубль/заглушку в вариант использования вместо того, чтобы издеваться над адаптером.
Я действительно не получаю этих отрицательных голосов без объяснения причин. Зачем существует тег «Шестиугольная архитектура», если о ней нельзя говорить?