и представляет инфу о 4 вариантах с плюсами и минусами

и после этого выбирают подход и решают им подобные случаи

если выбор окажется неправильный то меняют его, а также меняют все решения принятые по неверному подходу (рефакторят)

это не поток сознания так в идеальном случае должно быть

1. самодурство это плохо, если у тебя есть команда 2. у каждого способа есть свои плюсы и минусы - тебе надо очень хорошо понимать проблемы которые тебе надо решать и потом уже выбирать подходы 3. команда участвует в формировании стратегии 4. все эти правила можно нарушать в угоду скорости разработки. Например если ты разбил на модули а потом всплыло что не правильно разбил. ибо тогда чего-то не понимал. Это нормально и просто потом рефакторится.

мое мнение - большинство не особо четко понимает проблемы которые есть на проекте

и потому выбирают не совсем верные подходы

проиграть тут легко

или не хочет понимать или не заинтересован

потому проще не загоняться и просто делать регулярно ретроспективы и оценку состояния дел

или не хочет понимать или не заинтересован

такое тоже бывает.

у меня интересный опыт тут есть

мы на ретрах техническую часть не обсуждаем

к сожалению

надо предложить будет обсуждение технических вещей и тех ретро

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

мы на ретрах техническую часть не обсуждаем

ну мы обсуждаем только то что всю команду аффектит, а так у нас есть раз в 2 недели просто общие митинги бэкэндщиков где мы обсуждаем проблемы и то что мы видим "плохо мол надо что-то делать"

ой, раз в неделю

ну мы обсуждаем только то что всю команду аффектит, а так у нас есть раз в 2 недели просто общие митинги бэкэндщиков где мы обсуждаем проблемы и то что мы видим "плохо мол надо что-то делать"

у нас нет сбора бэкэндщиков(((

организуй) вещь полезная)

надо эту идею перенять

если только этим заниматься

у нас чатик есть в слаке

я там обычно гавно на вентилятор кидаю или разъебываю модули0

сразу скажу - мы когда начинали - первые месяца 3 наверное я могу оценить полезность сего мероприятия как "люди собрались и поныли"

да

я вот думаю как эту стадию пропустить бы)

я сам ною часто как плохо

и предлагаю роад мап по улучшениям

но все приходится или делать самому

правя другие таски

1. собери у людей проблемы, то есть пара митингов у тебя всеравно будет с нытьем 2. назначать ответственных по проблемам что бы люди думали как проблемы решать и потом презентавали решения возможные

потому что все заняты тущениями пожаров

без второго пункта активных участников будет ну может 1-2

и они потом перегорят)

как со мной было

у нас чуть чуть демократично все)

и все равноправны

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

но идея начать с тех митингов и общения по бэкенду это здорово

кого что бесит

в бэкенде и что надо править

на основе этого брать таски в спринт

хотя бы повышать приоритет.

спс Сергей, попробую предложить

вообще если у тебя есть представления о бэклоге на 1-2 спринта в перед - то легко приоритизировать что надо фиксить и закладывать это в сами задачи

надо записать в конце спринта на ретро предложу)

проблема в том что у нас большинство решений что мы делаем

придется переделывать((( по чуть чуть

наш сервис это некий агрегатор над другими сервисами разного уровня кривизны

по чуть чуть, тут главное терпение

это да

и понимание того как какие-то проблемы вас аффектят

у меня на проекте есть парочка моих "косяков" которые тянутся уже полгода и я все хочу этим заняться но... оно не очень болит, просто не красиво и неудобно

я уже хотел тех талки предложить

но забыл чето

я предлагал совместное обучнеие

у нас это практиковалось раньше....

но чет как-то заглохло

ERROR: S client not available

чтобы в команде делится знаниями (у людей скилл подрос) ну и менятся знаниями о системе

потом начал стримить в том числе для нас

но сейчас на работе только я кидаю ссылки

на обучение или семинары

хотя бы повышать приоритет.

Отошел на 5 минут. +200 сообщений. Например я хочу получить посты авторо которого foo barович. При Applicatio level join. Я обращаюсь к репозиторию модуля и достаю оттуда id. Далее кидаю запрос в модуль постов и получаю их. Все эио соединяю и отдаю юзеру. В sql просто через джоины фигачу запрос и получаю ответ. А все это будет хранится в некотором модуле ui, который я создал специально для репрезентации данных. Все верно я понял?

тип того, идея такая

http://qualityisspeed.blogspot.com.by/2014/09/beyond-solid-dependency-elimination.html

тип того, идея такая

Я в тупике. Раньше я делал так. У меня есть бандл. В нем стандартное дерево каталогов. В папке controller было разделение на admin/frontend и api если нужно. Меня заинтересовал вопрос разделения структуры проекта, так как количество сущностей в каталоге Entity возрастает с каждым днем. И мне это очень не нравится. Мне понравился подход с разделением на модули. Но получается теперь необходимо создавать 3 отдельных модуля под api, frontend и admin( а так же console), которые будут разруливать запросы к приложению. То есть в этих папках будут желать контроллеры, action'ы, которые будет взаимодействовать с каждым модулем в проекте. То есть они будут знать обо всем. Это нормально? Я не могу прийти к удовлитворительному уровню декомпозиции системы. Или не обращать внимания на большое количество файлов в директориях ?) Может кто поделиться организацией больших проектов ?)

> То есть они будут знать обо всем. Это нормально? ну не обовсем, если у тебя есть 4 модуля которые знают о всех остальных модулях и все юзают одно и то же - то имеет смысл объеденить в один

вообще вся проблема в использовании структуры как способе нейминга что не хорошо. Это и папки Entity, и всякие SomethingRepository

http://qualityisspeed.blogspot.com.by/2014/09/beyond-solid-dependency-elimination.html

• Single Responsibility Principle: Heck yes. Whole Values everywhere. Extremely high cohesion. - кажется чувак не понял смысла SRP

• Single Responsibility Principle: Heck yes. Whole Values everywhere. Extremely high cohesion. - кажется чувак не понял смысла SRP

может ты не правильно понял смысл SRP?)

?

может ты не правильно понял смысл SRP?)

может. как Whole Values гарантируют, что у сущности только один источник изменений?

Я в тупике. Раньше я делал так. У меня есть бандл. В нем стандартное дерево каталогов. В папке controller было разделение на admin/frontend и api если нужно. Меня заинтересовал вопрос разделения структуры проекта, так как количество сущностей в каталоге Entity возрастает с каждым днем. И мне это очень не нравится. Мне понравился подход с разделением на модули. Но получается теперь необходимо создавать 3 отдельных модуля под api, frontend и admin( а так же console), которые будут разруливать запросы к приложению. То есть в этих папках будут желать контроллеры, action'ы, которые будет взаимодействовать с каждым модулем в проекте. То есть они будут знать обо всем. Это нормально? Я не могу прийти к удовлитворительному уровню декомпозиции системы. Или не обращать внимания на большое количество файлов в директориях ?) Может кто поделиться организацией больших проектов ?)

по факту тебе надо просто разложить все так, что бы уменьшить количество завимисостей между модулями, что бы то что меняется вместе лежало вместе, а что порзнь пусть лежит порознь. Ну и еще - сразу сделать нормально не выйдет - просто прими это и чаще рефактори

может. как Whole Values гарантируют, что у сущности только один источник изменений?

ну типа у каждого VO своя зона ответственности

одно поведение, диктуемое одной конкретной ролью

там есть ссылки на другие примеры

ну то есть в этой фразе что мол у нас теперь все кохизив - это упрощено

по факту у тебя реально разделение проекта произошло так, что бы максимально минимизировать количество зависимостей, что приводит собственно к кохизив. А если минимум зависимостей и все кохизив - значит и SRP мы соблюдаем

это считай "эталон" даже

p.s. я так и не дочитал про responsibility driven design, но там в целом схожие идеи были

а это типа источник вдохновения был у Боба когда он SRP сочинял

там и про выделение ролей, и про зоны ответственности, и про их пересечение и как их избегать

хотя в целом SRP и есть high coheasion + low coupling

https://gist.github.com/hellboy81/b1868aa7316e9905c210f5876521c957

у меня вопрос: то, что по ссылке - это антипаттерн?

там 2 if делают одно и тоже в клиентском коде и коде поставщика