что значит у нас ддд?

Тогда уж на локи. Транзакции ни как не помогают в конкуренции.

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

а что это может значить? по ддд проект пилим

что угодно, начиная "у нас есть папка сore domain" заканчивая "рисуем модели вместе с продактами и балуемся с domain storytelling"

ну вот до рисуем уже дошли
папками вроде никто не страдает)

а ну так норм

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

Думаю полезно будет почитать  the silent points главы "Common problems for teams starting out with DDD" из книги приниципы и практики DDD:

- The tactical patterns of DDD can guide you toward creating an effective domain model; however, this area of DDD is evolving, and the implementation details have been overemphasized. The patterns may have value, but this is not where the value of DDD lies.
DDD is far more than coding. Collaboration with domain experts to knowledge crunch and have a shared understanding of the problem domain expressed in a ubiquitous language are the pillars of DDD.
- Context is everything; context and isolation retain the integrity of your code. It reduces cognitive load and makes a model specific.
- You need a smart dedicated team willing to learn about the domain.
- You need access to a domain expert. Teams can’t reveal deeper insights without them.
- Use CRUD for bounded contexts with low complexity. You are not a bad programmer if you don’t have a domain model.
- Bounded context and the ubiquitous language are the foundation of DDD.
- DDD is about the process of learning, refining, experimenting, and exploring in the quest to discover a useful model in collaboration.

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

Тогда агрегаты немного бесполезные. Ибо они могут из-за паралельности нарушать логику работы используя устаревшие данные.

Прикрутить оптимистичные локи или пессимистичные совсем не сложно а спасает от многих плавающих багов

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

ну если у тебя пофиг значит по данным операции не пересекаются и странно что это один агрегат

а так оптимистик локи хотя бы надо да

Просто обычно это на уровне инфраструктуры для агрегатов. И странно что этого нет у вас . Они как бы такие себе агрегаты без этого.

получается с агрегатом в один момент времени должен работать только кто-то один, правильно? ну по дефолту, неважно какой агрегат и что за фича

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

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

агрегаты они клевые и в памяти но source of truth у тебя не в памяти твоего приложения. и мы потихоньку приходим ко всем прелестям распределенных данных.