контекст выбора товаров, контекст оформления заказа, контекст личного кабинета

это не контексты. это юз-кейсы.

контексты - это товары, заказы...

Это "может" (!!!) быть контекстом, если бизнес-правила уложатся в такую концепцию. Но мы их не знаем...

Ддд говно просто)

контексты - это товары, заказы...

У меня была ситуация когда вполне себе "товар" фигурировал в 4 контекстах

контекст выбора товаров, контекст оформления заказа, контекст личного кабинета

контекст стоимости товара, контекст характеристик товара.... по всякому можно дробить

это были 4 разных "товара"

нет, это были 4 контекста которые крутятся вокруг одной бизнес сущности но абсолютно независят друг от друга

нет, это были 4 контекста которые крутятся вокруг одной бизнес сущности но абсолютно независят друг от друга

Именно

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

но далеко не всегда верно

потому как они могут начать сильно пересекаться и "изоляция" пойдет по швам

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

Добрый вечер. По мотивам контекстов в DDD. Классический интернет магазин: товары, заказы, покупатели и т. д. На какие контексты вы разбили бы приложение?

- работа со стоимостью товаров - работа с наличием товаров - работа с доставкой заказа - работа с оформлением заказа - работа с платежками

я уже раз 10 сюда скидывал видос Уди а потому... там были ценные мысли по поводу выбора границ микросервисов... а они ничто иное как границы твоих контекстов.

точно, надо досмотреть вчера 20 минут глянул - правильные вещи говорит

https://www.youtube.com/watch?v=ez9GWESKG4I

вот еще интересное на тему

для этого нужно осилить ддд-книженцию а то кусочные знания это хорошо, но целостные лучше

для этого нужно осилить ддд-книженцию а то кусочные знания это хорошо, но целостные лучше

только вот без практики толку может и не быть, и без "боли" на проекте когда видешь зачем оно надо

ну само собой но без теории практика пользы не принесет

Добрый вечер. По мотивам контекстов в DDD. Классический интернет магазин: товары, заказы, покупатели и т. д. На какие контексты вы разбили бы приложение?

как пример можешь посмотреть вот сюда https://msdn.microsoft.com/en-us/library/jj591575.aspx

как пример можешь посмотреть вот сюда https://msdn.microsoft.com/en-us/library/jj591575.aspx

посмотри видосик выше - он чуть развернутее)

посмотри видосик выше - он чуть развернутее)

попросили пример, я скинул пример

посмотри видосик выше - он чуть развернутее)

я смотрел кстати

одно из первых по запросу "ddd bounded context"))

- работа со стоимостью товаров - работа с наличием товаров - работа с доставкой заказа - работа с оформлением заказа - работа с платежками

Спасибо

Небольшой вброс.

https://i.imgflip.com/23e0yn.jpg

+++

интересно почему, все ивенты в своих почтовых ящиках)

все сообщения*

интересно почему, все ивенты в своих почтовых ящиках)

ты не можешь: 1. гарантировать доставку 2. гарантировать последовательность 1. гарантировать доставку

https://i.imgflip.com/23e0yn.jpg

Отлично ?

ты не можешь: 1. гарантировать доставку 2. гарантировать последовательность 1. гарантировать доставку

it depends)

иногда могу

иногда нет)

иногда боль, иногда нет)

ну то есть и рожать иногда боль а иногда нет?

нормально делай, нормально будет

Парни вот вы всегда смеялись что в универе ООП преподают на примере геометирческих фигур, а мне пригодилось сегодня) Делаю сервис для вырезания лица из фотографии и такой вопрос. Как бы вы лучше сделали - много статических конструкторов у объекта Rectangle или фабрику которая отдает прямоугольники исходя из полученных параметров?

нормально делай, нормально будет

(с) Акушер

Мкушер

Парни вот вы всегда смеялись что в универе ООП преподают на примере геометирческих фигур, а мне пригодилось сегодня) Делаю сервис для вырезания лица из фотографии и такой вопрос. Как бы вы лучше сделали - много статических конструкторов у объекта Rectangle или фабрику которая отдает прямоугольники исходя из полученных параметров?

второе

ERROR: S client not available

я почему то не люблю фабрики

Парни вот вы всегда смеялись что в универе ООП преподают на примере геометирческих фигур, а мне пригодилось сегодня) Делаю сервис для вырезания лица из фотографии и такой вопрос. Как бы вы лучше сделали - много статических конструкторов у объекта Rectangle или фабрику которая отдает прямоугольники исходя из полученных параметров?

почему много?

разные данные могут быть. Например координата вернего левого и правого нижнего угла

координата центра и одного из угов

А что плохого в именованом конструкторе?

разные данные могут быть. Например координата вернего левого и правого нижнего угла

Не начнет ли тогда прямоуголтнмкт заниматься лишним ?

А что плохого в именованом конструкторе?

он не во всех языках доступен

Это минус языку :)

он не во всех языках доступен

ммм.... в большинстве доступен

я не имею ввиду статичные конструкторы (фабричные методы)

я вообще, судя по всему, не знаю языка с поддержкой именованных конструкторов - такое вообще бывает? :)

я вообще, судя по всему, не знаю языка с поддержкой именованных конструкторов - такое вообще бывает? :)

это и есть статические методы фабрики

или функции фабрики)

фабрика (не важно, в виде метода или отдельного класса) возвращает экземпляр, а конструктор выполняется при инициализации объекта.

википедия отсылает к Eiffel c "именованного конструктора"

ну в java можно провести аналогию с множественными сигнатурами конструктора

в плюсах тоже такое есть но это все же не именованный

это просто перегрузка

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

гайз, а подскажите норм чтиво по каплингу и кохешену (виды и тп)? wiki.c2?

лармана не предлагать

гайз, а подскажите норм чтиво по каплингу и кохешену (виды и тп)? wiki.c2?

"Clean architecture" Robert Martin

А кстати к чему здесь Ларман и почему его не предлагать?