На ранних этапах разработки важнее просто реализовать логику, исходя из текущих требований, чем пытаться сразу создать «идеальную» абстракцию.
Вам нужно видеть точки расширения вашего приложения и чем раньше вы их видите тем лучше. Программист с архитектурным мышлением лучше чем программист без него.
А драить, киссить и солидировать вы будете только на собеседовании, скорее всего)
В отличие от монолита, где все компоненты тесно связаны
Да хоспаде, если хорошо спроектировать систему то нету такой проблемы, проблема связанности компонентов давно обсуждается. Ну и микросервис это не решение, а те же проблемы только в профиль
Объяснить важность архитектуры это реальная проблема, по личному опыту даже в крупных, относительно, компаниях всем всеравно, дайте лишь бы что-то было и быстрее.
А какая разница? У вас так же данные приходят в удобном для вас виде и вы их обрабатываете, создаёте тип "запрос от клиента" и от него отталкиваетесь. Ну и собственно ваше DTO приходящие из вне уже какой-то тип который можно положить в какой-то конструктор.
После попадания ответа в конструктор вы можете делать что угодно - создавать объекты (фабрика) или создать 1 объект на весь пул данных. Автор изначального комментария актив рекордом смотрит, наверное
Можно попробую ответить?) Вы когда результат с базы получаете можете его весь протолкнуть под типом "результат получения заказа" в конструктор программного объекта и обработать.
Если честно в статье постоянно об что-то спотыкаешься (как будто вы сами не до конца разобрались) например:
Из функционального программирования я бы порекомендовал взять уважение к неизменяемым структурам данных и избегание сайд-эффектов, где это возможно (например, CQS).
Если открыть вашу ссылку на вики, то там видно что cqs это больше про ООП
Идея была в том что когда тебе лень, можно потрудиться (выучить построение кода в данном случае) чтобы потом меньше работать) Собственно архитектурные решения и направлены на уменьшение сложности работы над проектом) Но так как лень, тема не расскрыта
Проба своих литературных возможностей, смогу ли я передать свое чувство лени которое посетило меня в момент когда я открыл проект, и судя по первому комментарию к статье у меня получилось)
Ну и плюсом это ощущение на много сильнее и чаще появляется когда работаешь на "дядю"
Никто не спорит что мнение может поменяться. Про паттерны ООП я слышу примерно тоже самое, но мне и они нравятся. Цели убедить что именно какой-то "мой" подход в который я верю правильный у меня нету, как и доказывать что-то, пользуйтесь чем хотите, ну и собственно я буду пользоваться чем хочу.
Да кто страдает то, сейчас только и делают что от ООП отказываются, все никак отказаться не могут
Фишка не в этом, надо было топ в котором можно свой продукт на 1 место поставить (по каким критериям она топ-1 я так и не понял)
Вам нужно видеть точки расширения вашего приложения и чем раньше вы их видите тем лучше. Программист с архитектурным мышлением лучше чем программист без него.
А драить, киссить и солидировать вы будете только на собеседовании, скорее всего)
Да хоспаде, если хорошо спроектировать систему то нету такой проблемы, проблема связанности компонентов давно обсуждается. Ну и микросервис это не решение, а те же проблемы только в профиль
У IQueryable, как это относится к DDD чето не могу понять
Там вроде текучий интерфейс просто? Или типо того
А почему у вас в резюме тогда PHP указан?)
Может есть ссылка на работающий проект?
Объяснить важность архитектуры это реальная проблема, по личному опыту даже в крупных, относительно, компаниях всем всеравно, дайте лишь бы что-то было и быстрее.
А какая разница? У вас так же данные приходят в удобном для вас виде и вы их обрабатываете, создаёте тип "запрос от клиента" и от него отталкиваетесь. Ну и собственно ваше DTO приходящие из вне уже какой-то тип который можно положить в какой-то конструктор.
После попадания ответа в конструктор вы можете делать что угодно - создавать объекты (фабрика) или создать 1 объект на весь пул данных. Автор изначального комментария актив рекордом смотрит, наверное
Можно попробую ответить?) Вы когда результат с базы получаете можете его весь протолкнуть под типом "результат получения заказа" в конструктор программного объекта и обработать.
Если честно в статье постоянно об что-то спотыкаешься (как будто вы сами не до конца разобрались) например:
Если открыть вашу ссылку на вики, то там видно что cqs это больше про ООП
Ну и блок схемы ваши конечно прекрасны
Спасибо за поддержку, выгорание и правда важная тема в нашей работе. А так, это попытка выехать на отрицательном хейте, ну и к слову - 19к просмотров)
Идея была в том что когда тебе лень, можно потрудиться (выучить построение кода в данном случае) чтобы потом меньше работать) Собственно архитектурные решения и направлены на уменьшение сложности работы над проектом) Но так как лень, тема не расскрыта
Проба своих литературных возможностей, смогу ли я передать свое чувство лени которое посетило меня в момент когда я открыл проект, и судя по первому комментарию к статье у меня получилось)
Ну и плюсом это ощущение на много сильнее и чаще появляется когда работаешь на "дядю"
Ради этого все и затевалось
Из вашего сообщения следует что все ООП это DDD? Но не каждое DDD это ООП?))
Ну и кстати, если прослеживать комментарии с самого начала, то вы занимаетесь манипуляцией
А может и не быть ООП, правильно? Или DDD доступно только в проектах где ООП языки?
Никто не спорит что мнение может поменяться. Про паттерны ООП я слышу примерно тоже самое, но мне и они нравятся. Цели убедить что именно какой-то "мой" подход в который я верю правильный у меня нету, как и доказывать что-то, пользуйтесь чем хотите, ну и собственно я буду пользоваться чем хочу.
Спасибо за статью!