потому что все сидят в телеграме, а тут на тебе тормозящий слак )

Коллеги, я ищу специалиста, который сможет обучить команду разработки методу DDD в формате по скайпу. Парттайм в удобное время. Прошу написать в личку.

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

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

Проще воспользоваться элементами DDD - о том, как правильно пилить сложную продуктовую логику на bounded context-ы/domain/subdomain. Чтобы потом по ним распилить на микросервисы, внутри которых в 90 процентах случаев не будет никакого DDD - ни агрегатов, ни entities, ни value objects и т.д. Но поскольку они маленькие и простые, то этого и не особо надо.

Вы просто не умеете продавать баззворды! :D

DDD - базворд, да еще и устраревший. Сейчас в моде hexogonal arhcitecture на free монадах. Но оно вам надо? Помнится, я работал в одном там банке и у нас прям было прописано в конвеншенах - ВСЕГДА использовать Anemic Domain Model. Было множество попыток внедрить что-то еще, но в действительно сложной бизнес логике из DDD получается лапша, оно красиво только в книгах. Из Anemic Domain Model для сложной логики тоже получается лапша, но лапша простая и прямолинейная.

Попытка нарезать все на bounded context такая же стремная, как и порезать все на микросервисы с начала. Микросервисы и контексты веделяют, когда придет время. А начинать надо с простого монолита и анемичной модели.

Это правда. Но что надо начинать с анемичной модели - я, конечно, не согласен. Но начинать надо с маленького монолита, и как только им становится сложно управлять - делить. А дальше уже CQRS, Event Sourcing и прочие модные баззворды )

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

иногда я сразу вижу что мне придётся масштабировать, а что нет. А разработка микросервисов в гомогенной среде — дёшево

У меня скорее притенизия к подходу в целом - к догматичности - делай вот так и так, мы тут придумали супер-методики. Я не собираюсь внедрять вообще никакой продвинутой техники в начале проекта. Ни DDD, ни микросервисов, ни Client Driven Contracts (или что там в моде сейчас). Только самое простое и минимально работающее. Остальное добавлять по мере надобности.

Возвращяясь к банку, там в итоге для сложной бизнес логики свои паттерны вырабатывются специфичные для домена. У нас там были event buses, last value caches, rule engines, schedulers и всякое такое. Это действительно сложная логика. И где это все в DDD? :)

Возвращяясь к банку, там в итоге для сложной бизнес логики свои паттерны вырабатывются специфичные для домена. У нас там были event buses, last value caches, rule engines, schedulers и всякое такое. Это действительно сложная логика. И где это все в DDD? :)

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

Ага, шутки шутками, но есть языки которые ускоряют работу в 10-20 раз :)

да давайте про девопс