Фронты (каналы), бэкенды и BFF Сегодня на JVM Day познакомились с Маликом Сафиевым (рад знакомству, 🙌) и одну из затронутых тем хотелось бы вынести сюда. Итак, у вас есть фронт, бэк и между ними BFF, который переводит предметку бэка в предметку фронта (или не переводит). Вопросов два: 1. Должен ли форнт использовать предметку бэка? 2. Если не должен и на BFF есть ACL, то кто владеет BFF? Под фронтом будем понимать один и более каналов, вроде мобилки, виджетов, чего угодно. Зафиксируем несколько тезисов: 1. Фронт должен быть на языке той предметной области, в которой живут потребители фронта 2. Модель предметной области фронта и бэка может не совпадать Нам потребуется два паттерна DDD: 1. Conformist (когда один контекст использует модель другого контекста по тем или иным причинам) 2. ACL, когда один контекст защищает свою модель от модели другого Таким образом: - если предметка фронта и бэка совпадает (например, внутренний бэкофис, условная бухгалтерия, когда бэк автоматизирует бухгалтерию и с фронтом работают бухгалтеры), то это чистый Conformist - если предметка отличается (например, сложные налоговые расчеты в бэке сотвсякими сторно и другими страшными терминами, а фронт - обычные люди, которым нужно циферку налога увидеть, да уведомление подать и все это на обычном бытовом языке), то нужен ACL, он может быть на BFF и если это так, то этим BFF+ACL владеет фронт, так как BFF жестко связан с конкретным пользовательским опытом и именно фронт защищает свою предметку - на фронте может быть много моделей (вкладка для маркетолога, вкладка для сейла, вкладка для менеджера), тогда несколько ACL, каждым владеет команда соответствующего контекста, лучше, конечно, вести отдельные BFF в таком случае, но тогда архитектура усложняется и это важно учитывать Как мы видим, у фронта появляется потребность в бэк-компетенциях, так что использование BFF (и ACL на нем) это не только архитектурное, но и организационное решение. При этом сквозной функциональностью BFF, вроде безопасности или отказоустойчивости владеет платформенная команда.