похоже =) ... и это прикольно, честно. Я рад видеть похожие паттерны, это значит я (мы) попали туда, куда нужно. Это значит, что есть "боль", которую хочется закрыть. Но я не хочу учить декораторы, когда shallowReactive сделает все свойтва объекта, кроме приватных, реактивнымыми. Я хочу минимум нововведений.
После создания модели - все свойства, кроме приватных будут реактивными без всяких декораторов.
Я не хочу помнить о том, что нужно где-то вызвать destructor. И я не думаю, я просто использую контенер.
Так, ребята, из этого нужно делать проект, который будет выдавать плашки, которые можно вешать на github и в других системах. Я серьезно. Типа - уровень проекта, такие-то метрики.
Вы используете "кик-офф" в контексте планирования итерации или спринта. Вы уверены, что правильно понимаете его смысл?
Я погуглил
Кик-офф" (или установочная встреча) - это первая встреча участников проекта, на которой обсуждаются цели проекта, роли и обязанности участников, а также планы на будущее. Это важный этап, на котором устанавливаются общие ожидания и цели проекта, что помогает избежать путаницы и недоразумений в процессе работы.
Потому что мало кто создает слои, как отдельные папки. Т.е. создают папку для области, а в ней сразу папки для портов, моделей и т.п. Границы слоев не понятны.
Либо все это на самом верху, и тогда еще печальнее. Самый первый комментарий это подтверждает.
Это не все принципы, список дополняется по мере написания.
Нет смысла говорить о классах, и тем более о дереве, если нет понимания почему этот класс находится именно в этом месте. Это детали, нет проблем с созданием класса, когда понятна его ответственность. Понимание ответственности - это проблема.
Не возможно формировать структуру папок согласно дерева классов. если классы образую дерево через наследование , то будут большие проблемы. Лучше когда композиция. Но композиция не предполагает иерархии.
Модель проекта вообще невозможно спроектировать на уровне разработчика. Для этого нужно быть экспертом во всех доменных областях и примено представлять реализацию.
так... допустим... Собираем слои в пакет, кладем в папку pkg на "передержку". Что бы дозрел. Выносим пакет в отдельный репозиторий. Корзина релизится как пакет с версионностью и все дела. При этом пакет может содержать все три слоя, а может только 1 слой, а может сразу содержать все слои сконфигурированные в модуль. Здесь зависит от контекста.
Конечно, я сделаю сразу пакет, если точно уверен в его границах. Если не уверен не сделаю. Но я не знаю будущее, иначе я бы сейчас не писал коммент, а играл на бирже или в казино.
Не понимаю, как структура папок может масштабироваться. Что Вы имеете ввиду?
Я нигде не написал , что она масштабируется.
На данный момент я уверен, что она НЕ должна масштабироваться. Она должна эволиционировать в пакеты. Максимальная эволюция, когда проект состоит только из пактов и конфига. Моя структура этому не мешает, скорее даже способствует.
Всё верно. Так и происходит. После стабилизации границ модуля, его зависимостей, связей каждый модуль/компонент стремится превратиться в отдельный самостоятельный пакет в своём репозитории. Мы тоже так делаем.
Я сам программист никогда не понимал и не понимаю программистов, которые дают какие-то имена, и потом пишут комментарий к имени.
Например так
persistence/ # Реализации репозиториев driven/ ... и т.п.
Почему нельзя написать repository и т.д.? Там точно должны лежать репозитории?
У вас репозиторий это порт, по идее он в слое инфраструктуры или это часть бизнес логики. Так в каком слое он должен быть? А что если он хранит dto из слоя доменов? Так может быть? А репозитории может хранить данные как кэш, и периодически обновляться сам? Например, репа категории или складов. Где тогда он должен быть, почему это порт?
Наш, это чей? Российский? Если Вы так думаете, то могу огорчить - ситуация намного хуже. Так везде, и там тоже. Есть те у которых все правильно, и у которых не правильно. И это не зависит от размеров бизнеса. Это обычный человеческий фактор. Это из личного опыта.
Хоть так. Это создает предмет для диалога. Скрам-мастер может сказать: "я собрал метрики. К дедлайну мы успеваем сделать только ЭТО." Это должно вызвать обратную связь, иначе вы скорее всего в "болоте" или делаете проект в стол, ну... много вариантов есть.
нет, проблем не было. Но тут работают только стнадартные инструменты: debugger и console.
похоже =) ... и это прикольно, честно. Я рад видеть похожие паттерны, это значит я (мы) попали туда, куда нужно. Это значит, что есть "боль", которую хочется закрыть.
Но я не хочу учить декораторы, когда shallowReactive сделает все свойтва объекта, кроме приватных, реактивнымыми. Я хочу минимум нововведений.
После создания модели - все свойства, кроме приватных будут реактивными без всяких декораторов.
Я не хочу помнить о том, что нужно где-то вызвать destructor. И я не думаю, я просто использую контенер.
@alexey_ym, но это круто
Так, ребята, из этого нужно делать проект, который будет выдавать плашки, которые можно вешать на github и в других системах. Я серьезно. Типа - уровень проекта, такие-то метрики.
Мне кажется это прям полезно.
Радикальная прямота, красный скрам - много воды, какой-то рефлексии. Если её выкинуть, из книг будет статья
Вы используете "кик-офф" в контексте планирования итерации или спринта. Вы уверены, что правильно понимаете его смысл?
Я погуглил
Или это что-то другое?
Потому что мало кто создает слои, как отдельные папки. Т.е. создают папку для области, а в ней сразу папки для портов, моделей и т.п. Границы слоев не понятны.
Либо все это на самом верху, и тогда еще печальнее. Самый первый комментарий это подтверждает.
Это не все принципы, список дополняется по мере написания.
Нет смысла говорить о классах, и тем более о дереве, если нет понимания почему этот класс находится именно в этом месте. Это детали, нет проблем с созданием класса, когда понятна его ответственность. Понимание ответственности - это проблема.
Не возможно формировать структуру папок согласно дерева классов. если классы образую дерево через наследование , то будут большие проблемы. Лучше когда композиция. Но композиция не предполагает иерархии.
Модель проекта вообще невозможно спроектировать на уровне разработчика. Для этого нужно быть экспертом во всех доменных областях и примено представлять реализацию.
Все верно, согласен по всем пунктам. SFS структура более гибкая. То что написано в статье не конфликтует с вашим подходом, по смыслу это одно и тоже.
А... еще если Вы посмотрите на SFS структуру, то можете заметить, что это почти тоже самое что у Вас в первом комментарии.
Поэтому даже в моём контексте Ваша структура вполне логична и соотвествует тому, что написано в статье.
В моем понимании "масштабируется" и "разрастается" - это разные термины.
так... допустим... Собираем слои в пакет, кладем в папку pkg на "передержку". Что бы дозрел. Выносим пакет в отдельный репозиторий. Корзина релизится как пакет с версионностью и все дела. При этом пакет может содержать все три слоя, а может только 1 слой, а может сразу содержать все слои сконфигурированные в модуль. Здесь зависит от контекста.
Конечно, я сделаю сразу пакет, если точно уверен в его границах. Если не уверен не сделаю.
Но я не знаю будущее, иначе я бы сейчас не писал коммент, а играл на бирже или в казино.
Не понимаю, как структура папок может масштабироваться. Что Вы имеете ввиду?
Я нигде не написал , что она масштабируется.
На данный момент я уверен, что она НЕ должна масштабироваться. Она должна эволиционировать в пакеты. Максимальная эволюция, когда проект состоит только из пактов и конфига. Моя структура этому не мешает, скорее даже способствует.
Всё верно. Так и происходит. После стабилизации границ модуля, его зависимостей, связей каждый модуль/компонент стремится превратиться в отдельный самостоятельный пакет в своём репозитории. Мы тоже так делаем.
Я не знаю, что такое "Правильная структура". Я предпочитаю пользоваться термином - логичная.
Наверно, ваш вариант, в вашем контексте - логичный. В моём - нет.
Я сам программист никогда не понимал и не понимаю программистов, которые дают какие-то имена, и потом пишут комментарий к имени.
Например так
Почему нельзя написать repository и т.д.? Там точно должны лежать репозитории?
У вас репозиторий это порт, по идее он в слое инфраструктуры или это часть бизнес логики. Так в каком слое он должен быть? А что если он хранит dto из слоя доменов? Так может быть? А репозитории может хранить данные как кэш, и периодически обновляться сам? Например, репа категории или складов. Где тогда он должен быть, почему это порт?
А почему вы решили, что сборка зависимостей идет на уровне presentation? Не помню такого ни в одной из книг, которые я читал.
Наш, это чей? Российский? Если Вы так думаете, то могу огорчить - ситуация намного хуже. Так везде, и там тоже. Есть те у которых все правильно, и у которых не правильно. И это не зависит от размеров бизнеса. Это обычный человеческий фактор. Это из личного опыта.
Хоть так. Это создает предмет для диалога. Скрам-мастер может сказать: "я собрал метрики. К дедлайну мы успеваем сделать только ЭТО." Это должно вызвать обратную связь, иначе вы скорее всего в "болоте" или делаете проект в стол, ну... много вариантов есть.
у фрилансера как раз нет задач, у него обычно проекты, клиенты, а еще репутация. Флилансер знает цену дедлайнам.
Здесь https://www.sberbank.ru/ru/s_m_business/pro_business/deadline-chto-eto-prostymi-slovami-i-kak-ego-soblyudat
и здесь https://360.yandex.ru/blog/articles/dlya-chego-nuzhny-dedlajny-i-kak-s-nimi-podruzhitsya
и еще много где, так не считают.
ок. Ваш руководитель тоже думает, что это горизонт планирования? может лучше уточнить, вдруг это дедлайн?
это как вариант... но вы все правильно поняли. =)