Он у тебя на random() ошибку кидает?

а что значит "нетестируемый код"? Если я написал тест, запустил и он работает - это тестируемый код?

слишком общая фраза, которая не помогла никоим образом. Да и не представляю как она могла бы помочь)

мог бы просто сказать "ты пишешь какую то херню")

Если код за собой тянет полпроекта, если зависимости кода не инжектятся, если твой юнит - это не юнит, а кусок грязи, который умеет всё, если твой юнит создаёт сайдэффекты. Тут много придумать можно. И всё лечится чтением бородатых пердунов вроде Фаулера

не тянет пол-проекта, зависимостей нет значит не инжектятся, мой юнит - это юнит, не кусок грязи, всего не умеет, сайдэффектов не имеет (нет зависимостей вообще у него, на что можно сайдэффектить?). Фаулера читал

а когда он ломается? ты не назвал условия

И как у тебя тесты тогда ломаются? Они ломаться могут только от смены бизнес-требований или интерфейса

Либо где-то ты обманываешь

+

Бизнес-тркбования меняются, интерфейс тож меняется. А иногда не меняется

Я не говорил про изменения бизнес-требования,на повестке такого вообще не стояло

Были только сайд эффекты и ещё слова

Сорян, кофейная гуща кончилась

Я ваще хз че вы взялись гадать) я в первомсообщении указал, в чем у меня пробелы и я о них знаю)

Так что я не виноват в том что вы потратили кофейню гущу просто так

Всем привет! Такой вопрос. Есть аукцион (торги). После торгов площадка берет комиссию с участников торгов. Так же площадка выставляет счёт услуги.  У услуг есть пакеты Тарифов. Дальше будут внутренний счет, который можно пополнять.

Все это делаю независимо модульно. Общаются через шину данных. Как мне лучше сделать? Сейчас планирую так. Есть только аукцион.

Auction Service
- Member
...


Order Service
Invoice Service
Service Service
Payment Service

На русском:
Сервис Аукциона

Сервис заказов
Сервис счетов
Сервис услуг
Сервис платежей

Правильно ли такое разделение?

Либо последние 3 объединить в Finance, например?

Что-то запутался в простых вещах.

Сорян, кофейная гуща закончилась на мне)

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

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

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

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

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