Как научиться разрабатывать архитектуру приложения в области бизнес-логики?

Question

[raiboon]

Иногда попадаются проекты, где мозг буквально взрывается от количества бизнес-логики, а возможное количество вариантов разбиения бизнес-логики на объекты и их вложенность взрывается факториальной сложностью.
Что делать, чтобы как-то лучше научиться дизайнить как бизнес сущности лягут на базу/код? Как находить best-practises, чтобы быть более-менее уверенным, что так будет лучше?

Comments

[AlexHell]

я один заметил "чтобы быть более-менее уверенным, что так будет лучше" ? для вас, автор есть 2 пути:
1) перфекционизм - признать что вы хотите идеально сделать, выбрать самое-лучшее решение.. а тут всегда будет перебор множества вариантов, если надо лучшее
2) достаточно хорошее решение, на основе подумать + шаблоны (из прошлых проектов, книг, статей), может быть не идеальные иногда, но работающие.. впрочем тут тоже можно пострадать перфекционизмом и найти "самый лучший шаблон для Х, для Y, и т.п"

Answer 1

[dmitriy]

1. Хорошо спроектировать, и держать систему на виду помогает Event Storming + miro
2. На выходе мы имеем команды, события, сущности(агрегаты), информация, контекст
3. В зависимости от приложения элементы с 2 шага преобразуются в код

Comments

[raiboon]

С Event Storming не всегда все гладко, бизнес описывает так, как видит это сейчас и строго следовать этому зачастую оказывается нерасширяемым.

[Иван Шумов]

raiboon, на самом деле это заблуждение. Event Storming, по сути, позволяет лишь определить границы контекстов и создать интерфейсы для реализации. Расширяемостью это уже на вас, на реализации. И это уже к проектированием бизнес-логики никак не относится. Это Software Architecture в первую очередь, особенно разделы про SOA, виды connectivity и так далее

Answer 2

[Илья]

Читать GoF
Читать Эванса
Читать Фаулера
Читать много статей на тему с противоречащими друг другу мнениями.

Попробовать не только ООП, но и ФП

Много раз пробовать. Много думать.

Answer 3

[Максим Федоров]

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

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

Ну например есть некоторые правила дял построения акций:

• Если есть один товар такого-то критерия
  
• Если все товары такого-то критерия
  
• Если хотя бы один товар такого-то критерия
  
• Если ни один товар такого криетрия
  
• ...
  

Можно на каждый случай запрограть, особенно критерии то разные

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