Информация об изменениях

Сообщение Re: Многоуровневая архитектура vs Rest от 18.07.2019 13:48

Изменено 18.07.2019 14:52 RushDevion

Re: Многоуровневая архитектура vs Rest
S>Как считаете?

Считаю, что архитектура — это функция от требований к проекту.
Что вы пилите, в чем основная сложность (и, соответственно, риски) вашего проекта?
От этого будет зависеть то, как "правильно" строить архитектуру в вашем конкретном случае.
Если, например, это какая-то внутренняя админка — фигачте как проще и быстрее, еще сто раз переделаете.
Если ваш основной затык — перформанс, то не важно, как будет организован доменный слой. Надо твикать БД (оптимизация, индексы, шардинг и т.п.) и
думать на скейлингом (деплой, statefull/stateless инстансы и т.п.)
Если у вас сложная именно предметная область, то надо сосредоточиться на ней — реализовать доменный слой таким образом, чтобы
его можно было переиспользовать с любым типом внешнего интерфейса (REST, SOAP, шина, консольный или web UI и т.п.)
А вот если пока вообще непонятно, где ваша сложность (ну бывает и такое) — фигачьте как проще и быстрее, чтобы скорее получить фидбек и отрефакториться.
Re: Многоуровневая архитектура vs Rest
S>Как считаете?

Считаю, что архитектура — это функция от требований к проекту.
Что вы пилите, в чем основная сложность (и, соответственно, риски) вашего проекта?
От этого будет зависеть то, как "правильно" строить архитектуру в вашем конкретном случае.
Если, например, это какая-то внутренняя админка — фигачте как проще и быстрее, еще сто раз переделаете.
Если ваш основной затык — перформанс, то не важно, как будет организован доменный слой. Надо твикать БД (оптимизация, индексы, шардинг и т.п.) и думать на скейлингом (деплой, statefull/stateless инстансы и т.п.)
Если у вас сложная именно предметная область, то надо сосредоточиться на ней — реализовать доменный слой таким образом, чтобы его можно было переиспользовать с любым типом внешнего интерфейса (REST, SOAP, шина, консольный или web UI и т.п.)
А вот если пока вообще непонятно, где ваша сложность (ну бывает и такое) — фигачьте как проще и быстрее, чтобы скорее получить фидбек и отрефакториться.