React前端六边形架构疑问：适配器层数据过滤是否合规？

我正在基于六边形架构开发一个调用REST API的React前端小应用，目前遇到了一个困惑。为践行端口与适配器模式，我设计的文件夹结构如下：

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`

现在的问题是，iTunes API返回了约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;
  }
}

问题解答 #

1. 提前过滤完全符合六边形架构原则 #

六边形架构的核心是隔离领域逻辑与外部依赖，适配器层的核心职责就是处理外部系统（如iTunes API）与应用内部的交互，包括数据格式转换、适配外部数据结构。你在这里将外部API返回的冗余数据转换为应用内部需要的精简结构，正是适配器层的本职工作——让外部数据的结构变化无法影响到领域层和应用层。

反之，如果把过滤逻辑放到领域层，会导致领域层依赖外部API的具体数据结构，违反了六边形架构“领域层不依赖外部细节”的核心原则。领域层应只聚焦业务逻辑，而非外部API的字段构成。

2. 性能层面收益明确 #

• 内存占用优化：以100条数据为例，每条减少11个冗余属性，能显著降低应用内存占用，数据量越大效果越明显。
• 数据传递开销降低：虽然代理请求的原始响应大小不变，但前端解析后立即过滤，后续传递给应用层、领域层的数据量更小，减少了跨层数据传递的开销，也避免了后续不必要的属性访问操作。
• 代码维护性提升：应用层、领域层只需处理精简后的固定数据结构，无需关心外部API的复杂字段，降低了出错概率，代码可读性和可维护性大幅提升。

内容的提问来源于Stack Exchange，提问作者Álvaro