Так получилось, что в своем стремлении писать качественный код я сначала прочитал книгу Роберта Мартина «Чистая архитектура», а потом познакомился с архитектурной методологией Feature-Sliced Design. После этого меня не покидало чувство, что эти две вещи связаны.

Сегодня хочу поговорить о сущностях и бизнес-правилах.

В 20-й главе «Чистой архитектуры» бизнес-правила разделены на две категории: - критические бизнес-правила (правила из жизни, вне кода); - прикладные правила / сценарии (правила, живущие в коде).

Роберт Мартин говорит о том, что критические бизнес-правила должны жить в Entity (сущность), а прикладные правила / сценарии — в Use Case.

Я провел аналогию с FSD и предположил, что Entity из «Чистой архитектуры» по смыслу — то же самое, что слой Entity в FSD (неожиданно, не правда ли? 😁), а аналогом Use Case является слой Features в FSD.

Например: Формула расчета процента по кредиту — это правило, которое жило бы, даже если бы все банки вернулись к бумажным журналам и счетам. Это критическое бизнес-правило.

Логика отображения модального окна подтверждения покупки нужна только в контексте приложения. Это прикладное правило / сценарий.

Главный вывод, который я сделал для себя:

Если бизнес-правило можно объяснить человеку без единого упоминания «кнопки», «базы данных» или «API» — ему место в Entities.

Если же правило звучит так: «Перед оплатой пользователь должен подтвердить номер телефона, кликнув по кнопке „Подтвердить“», — это уже сценарий. Это Feature.

Теперь у меня есть четкий критерий: Сущность = бизнес сам по себе. Фича = бизнес в диалоге с пользователем через интерфейс.

Согласны ли вы с этой идеей?

Оговорюсь, что в контексте FSD бизнес-логику желательно инкапсулировать в сегментах model и lib. И, конечно же, пост — это просто пища для размышлений, а не истина в последней инстанции.

Всем добра!!!