LINUX.ORG.RU

Сообщения oxo

 

Архитектурообразующие принципы для категории кейзов

Допустим, у нас есть приложение, логика которого очень завязана на вызовы самых разнообразных сервисов (бд, очереди, API всех сортов, etc). Завязана настолько, что кажется, будто не надо выделять в приложении ядро — собственной доменной логики почти нет. Ограничивается кейзами `взял — проверил — взял где-то ещё, и ещё — проверил — отправил`.

Т.е. можно это рассматривать как умный брокер сообщений с вкраплениями логики.
Или лучше даже как https://ru.wikipedia.org/wiki/Манифольд

И получается такая инверсия — доменная логика зависит от всех апи-биндингов, а они, собственно, не зависят от ядра.

И это никак не укладывается в моей головушке, ощущение что я делаю что-то не так.

Может есть какие-то подходы для сего? Возможно, мне нужен этот ваш data driven development, но я что-то не очень понимаю без примера что это такое.

Собственно, преследуемые цели:

  • Разработка должна хорошо распараллеливаться
  • Структура должна по максимум сокращать время понимания кода и помогать интуитивно находить где какая логика находится
  • Удобное тестирование доменной логики

* под термином `ядро` подразумевается код, содержащий только доменную-логику, который требует на вход реализации интерфейсов, которые защищают его от внешнего отвратительного мира

 ,

oxo ()

fpconf

http://fpconf.ru/

2 декабря в москве будет конференция посвящённая функциональному программированию

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

 , , , ,

oxo ()

Кажется баг со счётчиком избранных тем

Кейз:

 

oxo ()

RSS подписка на новые темы