Телеграмм чат группы Android_Architecture страница 4512

И если детали описаны в ТЗ — то они становятся частью бизнес-логики.

Те кто пишут ТЗ мало имеют отношения к архитектуре. Там можно описать что угодно. Бизнес правила надо уметь выделять

17:49пожаловаться #1

KD

Боюсь у нас разный взгляд на эти вещи. Мое мнение, что не вся логика - бизнес-логика. Может быть логика в слое данных, связанная с детали транспортного слоя системы. Может быть логика отображения в презентере и она не бизнес тоже.

Вопрос как определить где какая - довольно творческий

Может быть.

Однако я тоже вижу разницу между логикой представления, бизнес-логикой и деталями реализации.

Когда тебе говорят реализовать что-то "конкретно так", то это уже не детали реализации.

17:49пожаловаться #2

KD

Те кто пишут ТЗ мало имеют отношения к архитектуре. Там можно описать что угодно. Бизнес правила надо уметь выделять

Под ТЗ я подразумеваю не конкретно ТЗ заказчика.
Это может быть тем, что вы решили на уровне вашей команды для реализации.

17:50пожаловаться #3

AV

Может быть.

Однако я тоже вижу разницу между логикой представления, бизнес-логикой и деталями реализации.

Когда тебе говорят реализовать что-то "конкретно так", то это уже не детали реализации.

Я руководствуюсь таким признаком. Что если поменяется правило хэширования, шифрования? Если я для тестов захочу убрать шифрование - повлияет ли это на поведение приложения?

Выглядит как замена базы данных, auth manager’а или любой другой способ получения авторизации. Значит это транспорт и слой данных, а не бизнес

17:52пожаловаться #4

KD

В примере с авторизацией — при проектировании авторизации вы в совокупности команд (фронт, бэк, безопасники, и т.д.) можете прийти к тому, что вместо отправки логина и пароля будете отправлять sha(username + password) — и это уже становится не деталями реализации, а именно бизнес-логикой.

17:52пожаловаться #5

KD

Я руководствуюсь таким признаком. Что если поменяется правило хэширования, шифрования? Если я для тестов захочу убрать шифрование - повлияет ли это на поведение приложения?

Выглядит как замена базы данных, auth manager’а или любой другой способ получения авторизации. Значит это транспорт и слой данных, а не бизнес

И на сервере сам поменяешь всё? И на других системах?

17:52пожаловаться #6

AV

И на сервере сам поменяешь всё? И на других системах?

Нет, я в своем приложении буду тестировать бизнес слой и передам ему репозиторий без шифрования.

17:53пожаловаться #7

KD

Нет, я в своем приложении буду тестировать бизнес слой и передам ему репозиторий без шифрования.

А к чему этот репозиторий без хэширования, если у тебя сервер ждёт именно такие данные?

17:53пожаловаться #8

AV

А к чему этот репозиторий без хэширования, если у тебя сервер ждёт именно такие данные?

К тому, что изменения на бэкэнде не повлияют на бизнес логику мобильного приложения. Не придется переписывать ни тесты бизнес-слоя, ни его код. Только изменить репозиторий для работы с ним.

Пользователь не увидит этих изменений тоже.

17:55пожаловаться #9

KD

У тебя есть endpoint у сервера для авторизации. Он ждёт от тебя одну единственную строку в теле запроса, которая представляет из себя sha(username + password).

Сервер именно так авторизует.
Ему не нужны голые логин и пароль ни в каком виде.

Причём тут детали реализации, если теперь на этом всё завязано и это явная бизнес-логика?

17:55пожаловаться #10

AV

У тебя есть endpoint у сервера для авторизации. Он ждёт от тебя одну единственную строку в теле запроса, которая представляет из себя sha(username + password).

Сервер именно так авторизует.
Ему не нужны голые логин и пароль ни в каком виде.

Причём тут детали реализации, если теперь на этом всё завязано и это явная бизнес-логика?

С точки зрения бизнес-слоя сервер ждет логин и пароль:) все остальное - деталь. Эндпоинт, шифрование, GET/POST

17:57пожаловаться #11

KD

С точки зрения бизнес-слоя сервер ждет логин и пароль:) все остальное - деталь. Эндпоинт, шифрование, GET/POST

Вот именно, что нет. В данном кейсе сервер ждёт именно хэшированную строку. Это полноценное бизнес-правило из которого вытекает конкретный юзкейс.

17:59пожаловаться #12

AV

Вот именно, что нет. В данном кейсе сервер ждёт именно хэшированную строку. Это полноценное бизнес-правило из которого вытекает конкретный юзкейс.

У нас разный взгляд на эти вещи) я не вижу причин почему это бизнес-правило.

18:01пожаловаться #13

KD

У нас разный взгляд на эти вещи) я не вижу причин почему это бизнес-правило.

Ничего страшного. Главное, чтобы твоё неведение не мешало коллегам:)

18:01пожаловаться #14

AV

Ничего страшного. Главное, чтобы твоё неведение не мешало коллегам:)

Это уже переход на личности. Вот скажи, если сервер ждет XML - это тоже бизнес-правило?

18:02пожаловаться #15

KD

Это уже переход на личности. Вот скажи, если сервер ждет XML - это тоже бизнес-правило?

Что? На какие личности, ты что придумываешь то:)

>если сервер ждет XML - это тоже бизнес-правило?
Нет.

18:03пожаловаться #16

AV

Что? На какие личности, ты что придумываешь то:)

>если сервер ждет XML - это тоже бизнес-правило?
Нет.

Почему sha(login+password) - это бизнес-правило, а xml/json нет? В чем отличие?

саша сок #KotlinGang... in Android Architecture

18:04пожаловаться #17

с#

Это уже переход на личности. Вот скажи, если сервер ждет XML - это тоже бизнес-правило?

про личности зря, автор ничего плохого не говорил.

18:05пожаловаться #18

AV

саша сок #KotlinGang

про личности зря, автор ничего плохого не говорил.

«Чтобы ваше неведение не мешало коллегам», слишком сильное утверждение

саша сок #KotlinGang... in Android Architecture

18:05пожаловаться #19

с#

У нас разный взгляд на эти вещи) я не вижу причин почему это бизнес-правило.

«Чтобы ваше неведение не мешало коллегам», слишком сильное утверждение

> я не вижу причин
https://t.me/Android_Architecture/103589

> Ничего страшного. Главное, чтобы твоё неведение не мешало коллегам https://t.me/Android_Architecture/103590

Вы уверены ?

Alex Vayts in Android Architecture