Идея была в том что когда тебе лень, можно потрудиться (выучить построение кода в данном случае) чтобы потом меньше работать) Собственно архитектурные решения и направлены на уменьшение сложности работы над проектом) Но так как лень, тема не расскрыта
Проба своих литературных возможностей, смогу ли я передать свое чувство лени которое посетило меня в момент когда я открыл проект, и судя по первому комментарию к статье у меня получилось)
Ну и плюсом это ощущение на много сильнее и чаще появляется когда работаешь на "дядю"
Никто не спорит что мнение может поменяться. Про паттерны ООП я слышу примерно тоже самое, но мне и они нравятся. Цели убедить что именно какой-то "мой" подход в который я верю правильный у меня нету, как и доказывать что-то, пользуйтесь чем хотите, ну и собственно я буду пользоваться чем хочу.
Что значит с логикой в сущностях? А если у вас не DDD, а ООП то логика где? Мне кажется вы тоже не так видите DDD, DDD это концепция бизнес разработки, когда все в контексте, все понимают что делают, как и для чего. Выделите в коде свои (бизнес) действия и выделите действия с инфраструктурой этого самого кода, напишите "словарь" для этого и ходите объясняйте-продавайте, что вы все за код цепляетесь, если вам нужно понизить сложность, есть прекрасные паттерны ООП, а еще есть теория что весь код (при попытке перейти на чистую архитектуру) скатывается к гексогональной архитектуре (где-то читал, не могу сейчас найти если честно) тоесть на взаимодействии через интерфейсы на уровне слоев.
В первом моем комментарии на который вы отвечали всетаки идет разговор про реализацию объектов в коде, это никак не зависит от бизнеса. Окей, если это правило DDD, то у меня свой DDD, от которого я взял все плюсы (по моему мнению) и все же программист решает что будет в коде, а не кто-то еще.
Функциональные программисты тоже могут решить бизнес задачу, и без объектов. Я маленько не об этом. Все же вы не сможете прямо на кодовых объектах общаться с бизнесом)
Мне кажется вы маленько не туда смотрите, всетаки проблема которую решает DDD - помощь при разработке, когда разработчик не погружен глубоко в область, по идее вы должны бизнес процессы перевести в код и общаться в компании в контексте этих кодовых процесов. Отсюда и часть проблемы будет уже ее решением (бизнес будет понимать что вы делаете с кодом, что меняете). Получается что по инверсии зависимостей все приложение будет зависить от бизнес контекста (домена), а не наоборот, что и придает некую чистоту проекту.
А как по факту там ООП или еще что-то, это маленько про другое. По поводу слоистости и чистоты (поддерживаемости кода), как мне кажется, разработчик рано или поздно сам приходит к этому, поэтому она, наверное, как некий факт воспринимается в контексте DDD.
Наверное потому что это в какой-то степени как картина, DDD у всех одно (условно простые фигуры/примитивы из рисования) но результат у всех разный, который зависит от компетенции архитектора.
Да и темболее, я сейчас читаю книгу банды четырёх, и там говорится что вы не можете просто взять код условного паттерна и вставить в свой проект, это больше про мысль, а так вы можете хоть все паттерны перемешать вместе, или один другим заменять, в книге они приводят примеры какой патерн можно каким заменить например.
Например в текущем проекте я взял что-то из MVC (контроллеры) и паттерн ООП - команда. Пользователь через точку входа (контроллер) отправляет запрос, формируется пул команд (от 1 до бесконечности) выполняется, обрабатывается и возвращается пользователю результат. Это все очень хорошо ложится друг с другом, и вникнуть в проект проще когда каждая его часть формализована, а не просто работает.
У вас не должно быть в проекте деление на DDD сущности и сущности базы данных. Система в базу должна сохранять результат выполнения своей логики. Мне например ближе TableModule и не надо никаких объектов городить с огромными конструкторами.
По поводу кстати большого количество переменных в конструкторе, в книге по ООП написано - метод должен ожидать в параметрах объект, а не кучу значений с указанием примитивов языка.
Идея была в том что когда тебе лень, можно потрудиться (выучить построение кода в данном случае) чтобы потом меньше работать) Собственно архитектурные решения и направлены на уменьшение сложности работы над проектом) Но так как лень, тема не расскрыта
Проба своих литературных возможностей, смогу ли я передать свое чувство лени которое посетило меня в момент когда я открыл проект, и судя по первому комментарию к статье у меня получилось)
Ну и плюсом это ощущение на много сильнее и чаще появляется когда работаешь на "дядю"
Ради этого все и затевалось
Из вашего сообщения следует что все ООП это DDD? Но не каждое DDD это ООП?))
Ну и кстати, если прослеживать комментарии с самого начала, то вы занимаетесь манипуляцией
А может и не быть ООП, правильно? Или DDD доступно только в проектах где ООП языки?
Никто не спорит что мнение может поменяться. Про паттерны ООП я слышу примерно тоже самое, но мне и они нравятся. Цели убедить что именно какой-то "мой" подход в который я верю правильный у меня нету, как и доказывать что-то, пользуйтесь чем хотите, ну и собственно я буду пользоваться чем хочу.
Спасибо за статью!
DDD это не только про код, тут надо брать 2 команды и сравнивать если вы хотите каких-то цифр.
А так, я в процесе работы сам пришел к чему-то похожему, все же мы одно дело делаем (стараемся).
Что значит с логикой в сущностях? А если у вас не DDD, а ООП то логика где? Мне кажется вы тоже не так видите DDD, DDD это концепция бизнес разработки, когда все в контексте, все понимают что делают, как и для чего. Выделите в коде свои (бизнес) действия и выделите действия с инфраструктурой этого самого кода, напишите "словарь" для этого и ходите объясняйте-продавайте, что вы все за код цепляетесь, если вам нужно понизить сложность, есть прекрасные паттерны ООП, а еще есть теория что весь код (при попытке перейти на чистую архитектуру) скатывается к гексогональной архитектуре (где-то читал, не могу сейчас найти если честно) тоесть на взаимодействии через интерфейсы на уровне слоев.
Промазал веткой
В текущем проекте они лежат в бизнес логике, но они не чистые table module, а с примесью entity
В первом моем комментарии на который вы отвечали всетаки идет разговор про реализацию объектов в коде, это никак не зависит от бизнеса. Окей, если это правило DDD, то у меня свой DDD, от которого я взял все плюсы (по моему мнению) и все же программист решает что будет в коде, а не кто-то еще.
Функциональные программисты тоже могут решить бизнес задачу, и без объектов. Я маленько не об этом. Все же вы не сможете прямо на кодовых объектах общаться с бизнесом)
Мне кажется вы маленько не туда смотрите, всетаки проблема которую решает DDD - помощь при разработке, когда разработчик не погружен глубоко в область, по идее вы должны бизнес процессы перевести в код и общаться в компании в контексте этих кодовых процесов. Отсюда и часть проблемы будет уже ее решением (бизнес будет понимать что вы делаете с кодом, что меняете). Получается что по инверсии зависимостей все приложение будет зависить от бизнес контекста (домена), а не наоборот, что и придает некую чистоту проекту.
А как по факту там ООП или еще что-то, это маленько про другое. По поводу слоистости и чистоты (поддерживаемости кода), как мне кажется, разработчик рано или поздно сам приходит к этому, поэтому она, наверное, как некий факт воспринимается в контексте DDD.
Объект в коде решает только задачу объекта в коде, есть процесс и вы его объясняете компьютеру (и себе) на объектах.
Что по вашему значит DDD сущность? Типо у вас половина кода DDD, а половина нет? Это ведь не так работает
Классно что есть люди кто думает своей головой и не ведётся на хайп
Наверное потому что это в какой-то степени как картина, DDD у всех одно (условно простые фигуры/примитивы из рисования) но результат у всех разный, который зависит от компетенции архитектора.
Да и темболее, я сейчас читаю книгу банды четырёх, и там говорится что вы не можете просто взять код условного паттерна и вставить в свой проект, это больше про мысль, а так вы можете хоть все паттерны перемешать вместе, или один другим заменять, в книге они приводят примеры какой патерн можно каким заменить например.
Например в текущем проекте я взял что-то из MVC (контроллеры) и паттерн ООП - команда. Пользователь через точку входа (контроллер) отправляет запрос, формируется пул команд (от 1 до бесконечности) выполняется, обрабатывается и возвращается пользователю результат. Это все очень хорошо ложится друг с другом, и вникнуть в проект проще когда каждая его часть формализована, а не просто работает.
Еще тут (всмысле на Хабре) говорят что на каждый микросервис нужна своя база данных, как по мне тоже в минус микросервисам это можно записать)
У вас не должно быть в проекте деление на DDD сущности и сущности базы данных. Система в базу должна сохранять результат выполнения своей логики. Мне например ближе TableModule и не надо никаких объектов городить с огромными конструкторами.
По поводу кстати большого количество переменных в конструкторе, в книге по ООП написано - метод должен ожидать в параметрах объект, а не кучу значений с указанием примитивов языка.