Вы используете "кик-офф" в контексте планирования итерации или спринта. Вы уверены, что правильно понимаете его смысл?
Я погуглил
Кик-офф" (или установочная встреча) - это первая встреча участников проекта, на которой обсуждаются цели проекта, роли и обязанности участников, а также планы на будущее. Это важный этап, на котором устанавливаются общие ожидания и цели проекта, что помогает избежать путаницы и недоразумений в процессе работы.
Потому что мало кто создает слои, как отдельные папки. Т.е. создают папку для области, а в ней сразу папки для портов, моделей и т.п. Границы слоев не понятны.
Либо все это на самом верху, и тогда еще печальнее. Самый первый комментарий это подтверждает.
Это не все принципы, список дополняется по мере написания.
Нет смысла говорить о классах, и тем более о дереве, если нет понимания почему этот класс находится именно в этом месте. Это детали, нет проблем с созданием класса, когда понятна его ответственность. Понимание ответственности - это проблема.
Не возможно формировать структуру папок согласно дерева классов. если классы образую дерево через наследование , то будут большие проблемы. Лучше когда композиция. Но композиция не предполагает иерархии.
Модель проекта вообще невозможно спроектировать на уровне разработчика. Для этого нужно быть экспертом во всех доменных областях и примено представлять реализацию.
так... допустим... Собираем слои в пакет, кладем в папку pkg на "передержку". Что бы дозрел. Выносим пакет в отдельный репозиторий. Корзина релизится как пакет с версионностью и все дела. При этом пакет может содержать все три слоя, а может только 1 слой, а может сразу содержать все слои сконфигурированные в модуль. Здесь зависит от контекста.
Конечно, я сделаю сразу пакет, если точно уверен в его границах. Если не уверен не сделаю. Но я не знаю будущее, иначе я бы сейчас не писал коммент, а играл на бирже или в казино.
Не понимаю, как структура папок может масштабироваться. Что Вы имеете ввиду?
Я нигде не написал , что она масштабируется.
На данный момент я уверен, что она НЕ должна масштабироваться. Она должна эволиционировать в пакеты. Максимальная эволюция, когда проект состоит только из пактов и конфига. Моя структура этому не мешает, скорее даже способствует.
Всё верно. Так и происходит. После стабилизации границ модуля, его зависимостей, связей каждый модуль/компонент стремится превратиться в отдельный самостоятельный пакет в своём репозитории. Мы тоже так делаем.
Я сам программист никогда не понимал и не понимаю программистов, которые дают какие-то имена, и потом пишут комментарий к имени.
Например так
persistence/ # Реализации репозиториев driven/ ... и т.п.
Почему нельзя написать repository и т.д.? Там точно должны лежать репозитории?
У вас репозиторий это порт, по идее он в слое инфраструктуры или это часть бизнес логики. Так в каком слое он должен быть? А что если он хранит dto из слоя доменов? Так может быть? А репозитории может хранить данные как кэш, и периодически обновляться сам? Например, репа категории или складов. Где тогда он должен быть, почему это порт?
Наш, это чей? Российский? Если Вы так думаете, то могу огорчить - ситуация намного хуже. Так везде, и там тоже. Есть те у которых все правильно, и у которых не правильно. И это не зависит от размеров бизнеса. Это обычный человеческий фактор. Это из личного опыта.
Хоть так. Это создает предмет для диалога. Скрам-мастер может сказать: "я собрал метрики. К дедлайну мы успеваем сделать только ЭТО." Это должно вызвать обратную связь, иначе вы скорее всего в "болоте" или делаете проект в стол, ну... много вариантов есть.
На это нужно время, извини, но я не готов сейчас потратить. Могу кратко изложить свои подходы проектирования.
я не думаю о домене как слое внутри слоя приложения. Здесь граница сильно размыта. Эта часть сама проявится, когда будут четко выстроены границы слоев. Для меня домен - это ограниченный контекст, далее я буду использовать его именно так.
я знаю, что есть 4 слоя: приложение, инфраструктура, контроллеры и конфигурация. Приложение и конфигурация могут отсутствовать.
я знаю, что приложение это главный слой, все "подстраиваются" под него, кроме конфигурации. Конфигурация - это композиция компонент.
я знаю, что есть вертикальные зависимости между слоями (внутренние зависимости домена) и горизонтальные, внутри слоя между разными доменами (внешние зависимости домена). Слои и домены образуют "решетку".
я осознанно сильно связываю вертикальные (внутренние) зависимости между слоями внутри домена и делаю конструкцияю прочной по вертикали. В вертикале я не использую абстракции, если возможно. Это противоречит DIP, но сильно уменьшает когнитивную сложность. Это связано с тем, что вероятность вертикальных изменний мала без изменения слоя приложения.
я использую абстракции для вненших зависимостей, делая домен слабосвязанным. Соседние домены могут легко меняться независимо.
я знаю, что есть поток данных. Он движется вертикально по слоям внутри домена в двух направлениях: сверху - вниз и обратно. Зная, что слой приложения главный и понимая какой поток обрабатывает текущий код, я понимаю, куда ставить мапперы и фабрики. Их позиция может меняться в зависимости от задачи, но у меня всегда есть ответ на вопрос - почему они здесь.
Очень малелький пример конфигурации такого подхода описан здесь с статье "Еще раз про Di-контейнеры в golang" раздел "Применяем в реальном проекте"
Это не так. Мапперы, которые отвечают за преобразование данных при переходе между слоями, должны быть в точно определённых местах нижних уровнях. Если у вас это не так, скорее все у вас нарушение зависимости слоев.
Радикальная прямота, красный скрам - много воды, какой-то рефлексии. Если её выкинуть, из книг будет статья
Вы используете "кик-офф" в контексте планирования итерации или спринта. Вы уверены, что правильно понимаете его смысл?
Я погуглил
Или это что-то другое?
Потому что мало кто создает слои, как отдельные папки. Т.е. создают папку для области, а в ней сразу папки для портов, моделей и т.п. Границы слоев не понятны.
Либо все это на самом верху, и тогда еще печальнее. Самый первый комментарий это подтверждает.
Это не все принципы, список дополняется по мере написания.
Нет смысла говорить о классах, и тем более о дереве, если нет понимания почему этот класс находится именно в этом месте. Это детали, нет проблем с созданием класса, когда понятна его ответственность. Понимание ответственности - это проблема.
Не возможно формировать структуру папок согласно дерева классов. если классы образую дерево через наследование , то будут большие проблемы. Лучше когда композиция. Но композиция не предполагает иерархии.
Модель проекта вообще невозможно спроектировать на уровне разработчика. Для этого нужно быть экспертом во всех доменных областях и примено представлять реализацию.
Все верно, согласен по всем пунктам. 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
и еще много где, так не считают.
ок. Ваш руководитель тоже думает, что это горизонт планирования? может лучше уточнить, вдруг это дедлайн?
это как вариант... но вы все правильно поняли. =)
На это нужно время, извини, но я не готов сейчас потратить. Могу кратко изложить свои подходы проектирования.
я не думаю о домене как слое внутри слоя приложения. Здесь граница сильно размыта. Эта часть сама проявится, когда будут четко выстроены границы слоев. Для меня домен - это ограниченный контекст, далее я буду использовать его именно так.
я знаю, что есть 4 слоя: приложение, инфраструктура, контроллеры и конфигурация. Приложение и конфигурация могут отсутствовать.
я знаю, что приложение это главный слой, все "подстраиваются" под него, кроме конфигурации. Конфигурация - это композиция компонент.
я знаю, что есть вертикальные зависимости между слоями (внутренние зависимости домена) и горизонтальные, внутри слоя между разными доменами (внешние зависимости домена). Слои и домены образуют "решетку".
я осознанно сильно связываю вертикальные (внутренние) зависимости между слоями внутри домена и делаю конструкцияю прочной по вертикали. В вертикале я не использую абстракции, если возможно. Это противоречит DIP, но сильно уменьшает когнитивную сложность. Это связано с тем, что вероятность вертикальных изменний мала без изменения слоя приложения.
я использую абстракции для вненших зависимостей, делая домен слабосвязанным. Соседние домены могут легко меняться независимо.
я знаю, что есть поток данных. Он движется вертикально по слоям внутри домена в двух направлениях: сверху - вниз и обратно. Зная, что слой приложения главный и понимая какой поток обрабатывает текущий код, я понимаю, куда ставить мапперы и фабрики. Их позиция может меняться в зависимости от задачи, но у меня всегда есть ответ на вопрос - почему они здесь.
Очень малелький пример конфигурации такого подхода описан здесь с статье "Еще раз про Di-контейнеры в golang" раздел "Применяем в реальном проекте"
Это не так. Мапперы, которые отвечают за преобразование данных при переходе между слоями, должны быть в точно определённых местах нижних уровнях. Если у вас это не так, скорее все у вас нарушение зависимости слоев.
Здесь вопрос в другом - где лежат мапперы и, главное, почему?
Это важно. Если они лежатт не там где надо, то в других местах тоже возникнут проблемы.