AM
Я говорю, как суперкласс
Size: a a a
2021 February 09
SB
Alex Menzfolder
А это к чему?
к тому что нет методов
В моем языке нет структур поэтому для сообщений приходится классы использовать вместо структур
В моем языке нет структур поэтому для сообщений приходится классы использовать вместо структур
MM
Alex Menzfolder
Я говорю, как суперкласс
прими таблетки
AM
к тому что нет методов
В моем языке нет структур поэтому для сообщений приходится классы использовать вместо структур
В моем языке нет структур поэтому для сообщений приходится классы использовать вместо структур
Ясно...
2021 February 10
SB
халп
простой (ХЗ, на самом деле не очень) вопрос. Стоит ли держать спеку (напр. OAS) в отдельной от эндпоинтов, которые она описывает, репе?
Ну тип если рассмотреть монорепо-проект - часто всю спеку полностью кладут в отдельную папку. У нас проблема в том, что хотят запихнуть спеку по всем эндпоинтам (которые в разных репах) в одну общую репу документации.
Мне кажется, что с точки зрения кохижена и каплинга лучше всего пихать спеку к тому модулю, который спека описывает, это упростит изменения(не надо делать коммит в 2 репозитория по 1 фиче), удобнее будет подключать валидацию по json-schema.
Кто как делает?
простой (ХЗ, на самом деле не очень) вопрос. Стоит ли держать спеку (напр. OAS) в отдельной от эндпоинтов, которые она описывает, репе?
Ну тип если рассмотреть монорепо-проект - часто всю спеку полностью кладут в отдельную папку. У нас проблема в том, что хотят запихнуть спеку по всем эндпоинтам (которые в разных репах) в одну общую репу документации.
Мне кажется, что с точки зрения кохижена и каплинга лучше всего пихать спеку к тому модулю, который спека описывает, это упростит изменения(не надо делать коммит в 2 репозитория по 1 фиче), удобнее будет подключать валидацию по json-schema.
Кто как делает?
Давай начнём с простого: зачем нужна спека? То есть как вы планируете её использовать? Если "вручную" - то вполне можно держать в том же репо. Если вы используете contract-based testing, то эта спека тоже ещё не весь контракт, видимо, и её тоже можно держать в том же репо. Это удобно ещё и тем, что на этапе ревью пулреквеста можно посмотреть, как собственно изменилась спека, и даже, возможно, посмотреть автомагически на schema evolution и совместимость. И это в принципе не зависит от того, отталкиваетесь от спеки или генерите её из кода.
SP
халп
простой (ХЗ, на самом деле не очень) вопрос. Стоит ли держать спеку (напр. OAS) в отдельной от эндпоинтов, которые она описывает, репе?
Ну тип если рассмотреть монорепо-проект - часто всю спеку полностью кладут в отдельную папку. У нас проблема в том, что хотят запихнуть спеку по всем эндпоинтам (которые в разных репах) в одну общую репу документации.
Мне кажется, что с точки зрения кохижена и каплинга лучше всего пихать спеку к тому модулю, который спека описывает, это упростит изменения(не надо делать коммит в 2 репозитория по 1 фиче), удобнее будет подключать валидацию по json-schema.
Кто как делает?
простой (ХЗ, на самом деле не очень) вопрос. Стоит ли держать спеку (напр. OAS) в отдельной от эндпоинтов, которые она описывает, репе?
Ну тип если рассмотреть монорепо-проект - часто всю спеку полностью кладут в отдельную папку. У нас проблема в том, что хотят запихнуть спеку по всем эндпоинтам (которые в разных репах) в одну общую репу документации.
Мне кажется, что с точки зрения кохижена и каплинга лучше всего пихать спеку к тому модулю, который спека описывает, это упростит изменения(не надо делать коммит в 2 репозитория по 1 фиче), удобнее будет подключать валидацию по json-schema.
Кто как делает?
это контракт, потому в целом держать контракт отдельно от реализации не такая плохая идея
k
это контракт, потому в целом держать контракт отдельно от реализации не такая плохая идея
потому что реализация может меняться отдельно от контракта?
SP
СМ
Стоит ли определять интерфейсы классов в слое Предметной области, если их использует только слой Приложения?
СМ
Например, есть два интерфейса. Один отвечает за получение информации, другой за её отправку.
Обработчик в слое приложения занимается только связью этих двух интерфейсов.
Обработчик в слое приложения занимается только связью этих двух интерфейсов.
DE
халп
простой (ХЗ, на самом деле не очень) вопрос. Стоит ли держать спеку (напр. OAS) в отдельной от эндпоинтов, которые она описывает, репе?
Ну тип если рассмотреть монорепо-проект - часто всю спеку полностью кладут в отдельную папку. У нас проблема в том, что хотят запихнуть спеку по всем эндпоинтам (которые в разных репах) в одну общую репу документации.
Мне кажется, что с точки зрения кохижена и каплинга лучше всего пихать спеку к тому модулю, который спека описывает, это упростит изменения(не надо делать коммит в 2 репозитория по 1 фиче), удобнее будет подключать валидацию по json-schema.
Кто как делает?
простой (ХЗ, на самом деле не очень) вопрос. Стоит ли держать спеку (напр. OAS) в отдельной от эндпоинтов, которые она описывает, репе?
Ну тип если рассмотреть монорепо-проект - часто всю спеку полностью кладут в отдельную папку. У нас проблема в том, что хотят запихнуть спеку по всем эндпоинтам (которые в разных репах) в одну общую репу документации.
Мне кажется, что с точки зрения кохижена и каплинга лучше всего пихать спеку к тому модулю, который спека описывает, это упростит изменения(не надо делать коммит в 2 репозитория по 1 фиче), удобнее будет подключать валидацию по json-schema.
Кто как делает?
Про это https://youtu.be/NpyHPKipXmg
SP
Стоит ли определять интерфейсы классов в слое Предметной области, если их использует только слой Приложения?
а реализация где? В целом надо смотреть на направление зависимостей. Приложение зависит от предметной области - да. Предметная область зависит от приложения - нет. В общем и целом главное не думать про папки когда всем этим занимаешься а именно граф модулей смотреть, как там кружочки стрелочки друг на друга смотрят и что ты к чему относишь.
SP
Например, есть два интерфейса. Один отвечает за получение информации, другой за её отправку.
Обработчик в слое приложения занимается только связью этих двух интерфейсов.
Обработчик в слое приложения занимается только связью этих двух интерфейсов.
в этом случае вполне нормально. Реализация в этом случае будет вообще в инфраструктуре
DE
халп
простой (ХЗ, на самом деле не очень) вопрос. Стоит ли держать спеку (напр. OAS) в отдельной от эндпоинтов, которые она описывает, репе?
Ну тип если рассмотреть монорепо-проект - часто всю спеку полностью кладут в отдельную папку. У нас проблема в том, что хотят запихнуть спеку по всем эндпоинтам (которые в разных репах) в одну общую репу документации.
Мне кажется, что с точки зрения кохижена и каплинга лучше всего пихать спеку к тому модулю, который спека описывает, это упростит изменения(не надо делать коммит в 2 репозитория по 1 фиче), удобнее будет подключать валидацию по json-schema.
Кто как делает?
простой (ХЗ, на самом деле не очень) вопрос. Стоит ли держать спеку (напр. OAS) в отдельной от эндпоинтов, которые она описывает, репе?
Ну тип если рассмотреть монорепо-проект - часто всю спеку полностью кладут в отдельную папку. У нас проблема в том, что хотят запихнуть спеку по всем эндпоинтам (которые в разных репах) в одну общую репу документации.
Мне кажется, что с точки зрения кохижена и каплинга лучше всего пихать спеку к тому модулю, который спека описывает, это упростит изменения(не надо делать коммит в 2 репозитория по 1 фиче), удобнее будет подключать валидацию по json-schema.
Кто как делает?
И про контракты https://youtu.be/Bt5kC8KlpG8
k
И про контракты https://youtu.be/Bt5kC8KlpG8
тут бы хоть какие-нибудь писать =\
нам некогда!
нам некогда!
СМ
в этом случае вполне нормально. Реализация в этом случае будет вообще в инфраструктуре
А если эти интерфейсы поместить в слое Приложения, а реализацию в инфраструктуру?
Приложение настолько простое (по сути пересылает данные из одного источника в другой), что там просто нет бизнес-логики.
Приложение настолько простое (по сути пересылает данные из одного источника в другой), что там просто нет бизнес-логики.
DE
тут бы хоть какие-нибудь писать =\
нам некогда!
нам некогда!
Там суть, что если спека вынесена в отдельный репозиторий, то её можно обсуждать, менять и версионировать отдельно
k
Там суть, что если спека вынесена в отдельный репозиторий, то её можно обсуждать, менять и версионировать отдельно
нипаняяятна
MG
Обсуждать, менять и версионировать можно и не в отдельном репозитории. На вкус и цвет
DE
нипаняяятна
Команда A и команда B делают два сервиса, которые будут взаимодействовать по API. И они делают репозиторий для спеки.