вот начиналось все так красиво, шины данных, колаборативный домен... само то для CQRS :)

Определись по какому принципу ты определяешь разделение. Мол "логически" (logical cohesion, чуть лучше чем случайный кохижен) или же на основании того какие данные как меняются и какие данные влияют на эти изменения. Это довольно важно определиться чем руководствоваться при поиске границ ответственности.

Я бы рекомендовал тебе "имена" модулей выбирать в последний момент. Когда ты определился с тем какие модули какие юзкейсы хэндлят и какие данные для этих юзкейсов нужны. Мол "красный модуль позволяет нам делать ставки. для этого надо такие-то данные, зеленый модуль считает что-то еще - для этого ему нужны такие-то данные". Мотивация может быть в том что между модулями ты никак не можешь гарантировать что будешь работать с актуальными данными, что важно в условиях колаборативного домена. Ну либо у тебя будут распределенные локи и медленно (можно еще консистентные хэши и очереди но это надо оч хорошо партиции данных выбирать)

Имена модулей (особенно когда эти имена выбираются по бизнес сущностям) существенно влияют на то как ты будешь определять какие данные куда класть. Мол "но не логично в модуле счетов держать историю ставок, это ж аукционы".

1. если у тебя юниты ломаются так часто что прям свербит в душе то они слишком много знают о реализации.
2. когда тесты много знают о реализации это может говорить о большом количестве зависимостей или большом количестве сайд эффектов.
3. думаем как перераспределить работу с данными и логику так, что бы уменьшить количество сайд эффектов и зависимостей.
4. думать проще когда пишешь сначала тест и потом реализацию.
5. проблемные места можно находить по C.R.A.P. индексу или по соотношению сложности к количеству коммитов, или соотношение аферент эферент каплингов и цикломатической сложности... мол если сложный код и от него много кто зависит - надо писать тесты. Иначе умрешь. И полностью закрепить контракт. Если зависимостей мало меняется редко - может можно и забить.
6. хочешь написать комментарий для куска кода - напиши тест)
7. тесты не чувствуются таким дорогим удовольствием если начать мерять время (тупо за счет переключения между тестами и реализацией кажется что время тянется дольше), если не тестить руками (как минимум важные тест кейсы можешь упустить ибо руками уже проверил) + еще если тесты писать до реализации то ты совмещаешь время на написание тестов с временем на дизайн и продумывание требований к модулям)
8. юнит тесты это сложно потому что нет определения что такое юнит тесты и потому что юнит тесты про дизайн системы, изоляцию и декомпозицию. А это оч сложно.
9. Учим такой термин как return of investments и пытаемся прикинуть где нужны юнит тесты а где "ай и функциональных хватит". 5-ый пункт поможет.

В целом я хотел разделить все по логике) аукцион есть аукцион. Там свои сущности людей. Например, для аукциона нам не нужны реквизиты, а вот для выставления счетов нужны) Для заказа нужен Bayer. И так далее) поэтому и думаю как лучше разделить. Либо вообще каждый независим, либо как-то объединить.

https://en.wikipedia.org/wiki/Cohesion_(computer_science)

грубо говоря смотреть надо как данные между собой связаны. "бизнес сущности" можешь мысленно заменить на айдишки. Мол "у кастомера есть номер счета имя и адрес" можно представить как есть "адрес, номер счета и имя как отдельные сущности которые имеют одинаковый customer id". И уже дальше смотреть какие данные всегда нужны вместе (то есть влияют на инварианты) а какие нет, где можно разделить связь за счет сообщений а где нет... Это сложно да

вот начиналось все так красиво, шины данных, колаборативный домен... само то для CQRS :)

Определись по какому принципу ты определяешь разделение. Мол "логически" (logical cohesion, чуть лучше чем случайный кохижен) или же на основании того какие данные как меняются и какие данные влияют на эти изменения. Это довольно важно определиться чем руководствоваться при поиске границ ответственности.

Я бы рекомендовал тебе "имена" модулей выбирать в последний момент. Когда ты определился с тем какие модули какие юзкейсы хэндлят и какие данные для этих юзкейсов нужны. Мол "красный модуль позволяет нам делать ставки. для этого надо такие-то данные, зеленый модуль считает что-то еще - для этого ему нужны такие-то данные". Мотивация может быть в том что между модулями ты никак не можешь гарантировать что будешь работать с актуальными данными, что важно в условиях колаборативного домена. Ну либо у тебя будут распределенные локи и медленно (можно еще консистентные хэши и очереди но это надо оч хорошо партиции данных выбирать)

Имена модулей (особенно когда эти имена выбираются по бизнес сущностям) существенно влияют на то как ты будешь определять какие данные куда класть. Мол "но не логично в модуле счетов держать историю ставок, это ж аукционы".

Да нет тут ничего сложного

Но болит больше всего в юнитах, которые меняются с требованиями. Там вообще все и раскрываются все косяки неверно принятых решений

я вот из большой тройки только вью юзал, и то чутка. и мне прям понравилось. добавить мощную интерактивность в страницу - просто на изи

я вот из большой тройки только вью юзал, и то чутка. и мне прям понравилось. добавить мощную интерактивность в страницу - просто на изи

Если кому-то нужно попсовее и из коробки, то проще Laravel+Vue
Если по мощнее и академичнее, то Symfony+Angular
Если нужен контроль и кастомизация, то Slim+React

слим это про контроль?

Если кому-то нужно попсовее и из коробки, то проще Laravel+Vue
Если по мощнее и академичнее, то Symfony+Angular
Если нужен контроль и кастомизация, то Slim+React

а как же ламинас?)

слим это про контроль?

Все микрофреймворки – это про ручную сборку и полный контроль