ES
Тру стори
Size: a a a
2021 February 05
SP
но вообще это конечно обман. Секрет в тупых и понятных интерфейсах а код может быть и сложным
ES
Сложная грань. Если оценивать отдельные какие то пакеты то наверное да. Но в целом в проекте сложность кода оценивать приходится исходя из его реализации тех же интерфейсов
VS
Сложная грань. Если оценивать отдельные какие то пакеты то наверное да. Но в целом в проекте сложность кода оценивать приходится исходя из его реализации тех же интерфейсов
Ну как кажется, «тупой и понятный код» становится таковым, когда легко понять Что он делает, это про интерфейсы, а вот Как он это делает - это про реализацию и там у каждого всегда своё мнение все равно
ES
Ну как кажется, «тупой и понятный код» становится таковым, когда легко понять Что он делает, это про интерфейсы, а вот Как он это делает - это про реализацию и там у каждого всегда своё мнение все равно
Да, но вам же приходится в проектах поддерживать реализацию а не сами интерфейсы
DK
Human Human
Мне кажется это чисто интуитивное познание (опыт). Когда нужно запариться, а когда стоит сэкономить время.
Зависит от выделяемых ресурсов - это к менеджменту
DO
К слову про DDD - довольно интересный доклад https://www.youtube.com/watch?v=rFiuLeSFZsA
МХ
Может кто-то подсказать статью где с архитектурной точки зрения обосновывается преимущества выбора descriminated union для моделирования домена над флажком ? синяя книга по DDD и "Domain Modeling Made Functional" - это оно?
DS
Привет! Можете кинуть ссылку на какой-то крутой доклад/туториал/книгу/курс где классно описывается общение между сервисами на основе ивентов (Kafka в моем случае), пожалуйста?
А
К слову про DDD - довольно интересный доклад https://www.youtube.com/watch?v=rFiuLeSFZsA
На сколько бы Макс не был инетересен в обсуждениях деталей, вот этот доклад куча воды и абстракций как бы сделать хорошо
А
в реальности выглядит всё совершенно по другому, даже у него самого)
SP
Может кто-то подсказать статью где с архитектурной точки зрения обосновывается преимущества выбора descriminated union для моделирования домена над флажком ? синяя книга по DDD и "Domain Modeling Made Functional" - это оно?
это не то что бы "с архитектурной точки зрения" - слишком маленькие вещи. Это скорее про стилистику и выбранный язык.
В джавке какой ты так не сделаешь. Ну и пример твой больше про агрегацию композицию vs наследование. Лучше вообще избегать общих понятий типа User ибо скорее всего у тебя в куче контекстов оно будет фигурировать. Такие вещи лучше воспринимать как ID
В джавке какой ты так не сделаешь. Ну и пример твой больше про агрегацию композицию vs наследование. Лучше вообще избегать общих понятий типа User ибо скорее всего у тебя в куче контекстов оно будет фигурировать. Такие вещи лучше воспринимать как ID
SP
domain modeling made functional норм штука
SP
Привет! Можете кинуть ссылку на какой-то крутой доклад/туториал/книгу/курс где классно описывается общение между сервисами на основе ивентов (Kafka в моем случае), пожалуйста?
курс Уди - https://yadi.sk/d/CmSCZjdmhx4Ceg?w=1
подборка паттернов по интеграциям систем - https:// www.enterpriseintegrationpatterns.com/
доки MSDN на тему - https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/asynchronous-message-based-communication - там же еще ссылки
подборка паттернов по интеграциям систем - https:// www.enterpriseintegrationpatterns.com/
доки MSDN на тему - https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/asynchronous-message-based-communication - там же еще ссылки
DS
Спасибо всем.
МХ
это не то что бы "с архитектурной точки зрения" - слишком маленькие вещи. Это скорее про стилистику и выбранный язык.
В джавке какой ты так не сделаешь. Ну и пример твой больше про агрегацию композицию vs наследование. Лучше вообще избегать общих понятий типа User ибо скорее всего у тебя в куче контекстов оно будет фигурировать. Такие вещи лучше воспринимать как ID
В джавке какой ты так не сделаешь. Ну и пример твой больше про агрегацию композицию vs наследование. Лучше вообще избегать общих понятий типа User ибо скорее всего у тебя в куче контекстов оно будет фигурировать. Такие вещи лучше воспринимать как ID
спасибо
SB
Есть апи и 2 личных кабинета. Для админа и для клиента.
На сколько нормальная идея делать 2 разных апи эндпоинта?
Столкнулся с тем, что 80% методов по сути разные. Где то просто ответы разные в силу ограничения доступа к полям. Где то функционал относится только к одному из кабинетов.
Ну то есть я всегда считал, что апи вроде как должна быть client agnostic и бекенду должно быть фиолетово пришел к нему запрос от SPA или запрос по крону от партнёра
На сколько нормальная идея делать 2 разных апи эндпоинта?
Столкнулся с тем, что 80% методов по сути разные. Где то просто ответы разные в силу ограничения доступа к полям. Где то функционал относится только к одному из кабинетов.
Ну то есть я всегда считал, что апи вроде как должна быть client agnostic и бекенду должно быть фиолетово пришел к нему запрос от SPA или запрос по крону от партнёра
Отдельные, конечно. Backend for Frontend - отличный паттерн.
2021 February 06
DO
в реальности выглядит всё совершенно по другому, даже у него самого)
Хотелось бы конечно увидеть хоть какой то пример реального DDD)) я просто хочу научить студентов этому всему и соответственно хотелось бы примеры из практики с плюсами и минусами
SP
Хотелось бы конечно увидеть хоть какой то пример реального DDD)) я просто хочу научить студентов этому всему и соответственно хотелось бы примеры из практики с плюсами и минусами
Тут есть нюанс. DDD это про процесс моделирования. Модель тут артефакт. Глядя только на артефакты процесса сам процесс понятным не оч становится.
У тебя может быть гора тупых крудов (потому что удобная модель для твоего домена).
Есть занятная мысль что "сложность систем" надо рассматривать не только на основе кода который ты пишешь а с учетом сложности структуры организации вокруг. Человеческие системы весьма сложные даже если ты пилишь инстаграмы и если ты делаешь круды то всеравно есть проблема предсказуемости людей.
У тебя может быть гора тупых крудов (потому что удобная модель для твоего домена).
Есть занятная мысль что "сложность систем" надо рассматривать не только на основе кода который ты пишешь а с учетом сложности структуры организации вокруг. Человеческие системы весьма сложные даже если ты пилишь инстаграмы и если ты делаешь круды то всеравно есть проблема предсказуемости людей.