А в чем тогда его смысл как самостоятельного агрегата, если не секрет? На него единственное что можно сослаться из самого товара и потом постфактум проверить.
Но такой вариант не подходит, ибо в заказе может быть несколько позиций одного товара.
Т.е. мне все равно придется обходить весь заказ и пересчитывать все товары.
Пока решил это доменным сервисом, который никак не лезет в агрегат, но проверяет перед переходом корзины в заказ.

Вот сейчас аж больно было от слова rules engine- у в текущем проекте решили заиспользовать друлз ... и эта ебучая хрень тянет такие боли и страдания что бррр

https://www.youtube.com/watch?v=3gib0hKYjB0 кент бэк красавчик - вообще DDD europe интересно слушать )

Так проблема с тем как вы реализовали?

Тестируют ли валидацию аргументов по TDD? Скажем, я пишу PDOшку, которая должна получать строку строго определённого формата в конструктор. Для этого у неё есть валидаторы. Так как это питон, то они ещё тип аргумента проверяют. Тесты этих валидаторов не совсем по-моему входят в идеологию TDD.  С другой стороны, без тестов это оставлять как-то странно, ведь там наибольшая вероятность ошибок.
P.S. Валидация в данном случае не для юзера, а для программиста, который может неправильно инстанциировать PDOшки)

Или я загнался совсем 🤔

Tdd про философию — пишешь клиентский код (в виде тестов) и потом строго необходимый код (пишешь или меняешь)

Что именно и на каких слоях — об этом особо подход не говорит

Тут у тебя да, получается функциональный тес, правда независимо от подхода

Если прямо ответить: да, по ТДД тестируют...

Сначала пишут как все должно пройти (и оно не должно пройти), потом пишут и валидаторы ваши и pdo и и остальное; и ожидают, что тесты пройдутл

Тесты самих вплидаторов тоже подходят по тдд, если вы описали ожидания как они работают в тестах, и потом написали эти валидаторы... это будут юнит-тесты

более краткая версия - по TDD если нет красного теста значит не надо писать код. Если хочешь написать код - нужен красный тест. Через TDD ты задаешь требуемое поведение, контракт твоего объекта. если тебе надо что бы метод плевался ошибками - нужен красный тест для этой детали контракта.

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

В вашем случае это видится так:

Пишите функциональный тест (вам же нужна функциональность?)

Потом видите, что у вас нарисовывается при реализации какая-то архитектура (а не наоборот вы ее придумали до теста)

В ходе этой архитектуры вы видите, что нужны какие-то валидаторы — пишите тесты на них и реализуете уже их. Так с остальными частями

То есть тут вложенный процесс получается, по итогу ваш функц тест пройдёт

тут вопрос в том насколько ты хочешь делать гибко.

Если говорить скажем с позиции DDD то ты должен разобраться что в реальности происходит когда товары поступают на склад, как работает резервация и т.д. + ты никак не можешь избежать ситуации когда два чела попытаются купить последний айтем. Надо все равно как-то разруливать.

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

Ну или я не понял причем тут функциональные тесты - все тесты которые тестируют функциональность функциональные, это не сильно помогает людям обычно

Почему нельзя сначала подумать а потом делать? Это принципиальная точка зрения на процесс разработки?

Можно, тесты как раз и дают картину будущего  контракта

ну смысл TDD именно в том что бы сначала думать а потом делать.

А внутренности да, только из целесообразности

В сообщении как раз наоборот написано. Не думаем а делаем, а потом шо получится то и есть архитектура

просто не оч корректно говорить про "архитектуру" в контексте TDD. Все же длина итерации red-green-refactoring слишком короткая что бы из этого вышла путная архитектура

тут вопрос "о чем думать". TDD это про "думать о контрактах с точки зрения клиентского кода". Не про архитектуру да