Size: a a a

Software Design/Architecture/Zen

2021 May 31

СП

Сергей Предводителев... in Software Design/Architecture/Zen
чтобы в репозитории произошло получение репозитория, изменение и сохранение, да?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
как один из вариантов без сильных сложностей это организовать. И локи внутри тоже могут быть
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну то есть...

repo.get(id, (aggregate) => {
  aggregate.changeState()
})
источник

SP

Sergey Protko in Software Design/Architecture/Zen
просто и удобно. но подходит это вам или нет это уже надо разбираться. с этим подходом есть нюансы когда несколько агрегатов за операцию надо поменять. а такое случается чаще чем хотелось бы.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
если у тебя все операции потом через ивенты/политики разруливаются но "и так сойдет", но просто стоит быть осторожным что бы что-то между агрегатами нетак не пошло
источник

СП

Сергей Предводителев... in Software Design/Architecture/Zen
если несколько агрегатов, то это наверное какая-то транзакция растянутая во времени должна быть...
источник
2021 June 01

VN

Vladislav Navrocky in Software Design/Architecture/Zen
Господа, тут наверное уже неоднократно спрашивали про пример документации по канонам DDD? Я вот поиском не нашел ничего 😐 Меня конкретно интересует что должно быть в доке, какие пункты, какие диаграммы? Своим умом не совсем дохожу что там должно быть
источник

SP

Sergey Protko in Software Design/Architecture/Zen
источник

SP

Sergey Protko in Software Design/Architecture/Zen
вот можешь начать с этого.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
все остальное ничем не отличается
источник

VN

Vladislav Navrocky in Software Design/Architecture/Zen
Спасибо, посмотрю
источник

SP

Sergey Protko in Software Design/Architecture/Zen
основная проблема - разобраться для кого и с какой целью ты делаешь документацию. В контексте DDD важно задокументировать границы, что бы можно было оунершип командам задавать и комуникации направлять (то где кода не достаточно). Вот эта штука с этим помогает.
источник

m

militska in Software Design/Architecture/Zen
Начала тут Эванса читать, улыбнуло, что он не считает  зашкваром  в качетсве доки  зарисовки-схемы оставлять
источник

m

militska in Software Design/Architecture/Zen
*в том числе
источник

SP

Sergey Protko in Software Design/Architecture/Zen
а почему это может быть зашквар?
источник

m

militska in Software Design/Architecture/Zen
Не знаю, кажется, что  серьезней выглядят красивые доки  со струтурой в  вики. А зарисовка схемы работы, от руки/ даж перенесенная куда, уже как то не так.
хотя часто либо от руки, либо ни как =(
источник

BT

Bohdan Turchyk in Software Design/Architecture/Zen
вот именно поэтому - дока на коленке лучше, чем отсутствие доки
источник

SP

Sergey Protko in Software Design/Architecture/Zen
в доковидные времена норм тема собраться порисовать на вайтборде схемки сфоткать и залить в конфу/вики.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
какие-то из таких док можно "оформлять" красиво если твоя цель например сделать красивую анбординг документацию. Но если у тебя выбор "быстро накидать хоть какую-то доку" и "вылизывать шоб красиво" то лучше первое.
источник

EE

Evgenii Evgenivich in Software Design/Architecture/Zen
Ну....
Это же кому то нужно делать...
источник