За опечатку спасибо большое, поправлю, за создание лучше на мой взгляд можно использовать сервис по созданию сущности из которой будет запрос в бд на уникальность например тайтла и уже создание через фабрику(принимает уже валидные данные) сущности
Насчет название и смысла - так может показаться, если прийти к ValueObject через интуицию(то есть не прибегая к специализированному материалу). Например логика может быть такая: переводится как объект значение - ну тут все понятно)) Пойду кодить)))
Что же касается смысла, причин использования и примеры на мой взгляд интересных реализаций - это можно подсмотреть в книге Вон Верон "Предметно-ориентированное проектирование". Там достаточно подробно это все описано.
Опять же это мое видение. А что касается конкретного названия - смею предположить, что нужно было как то назвать этот подход и тут "Объект-значение" в контексте архитектурного подхода и в контексте синтаксиса выбранного языка программирование - может означать разный смысл. В первом случае(контекст подхода) - это осмысление текущего объекта со стороны бизнес логики Во втором случае(контекст синтаксиса ЯП) - можно предположить, как раз таки, что у объекта есть какое то значение и ни про какую бизнес логику или осмысление тут уже речь не идет.
И закончу ответ фразой: "Отвергаешь - предлагай". То есть, какое название с Вашей точки зрения - было бы удачное?
Насчет замечания по поводу исключений - такой подход так же имеет место быть. Я же хотел - как можно максимальнее сосредоточить статью на DTO и VO. Что бы все внимание досталось именно им.
Что же касается - логирования - в текущем контексте - это был лишь инструмент для того, что б показать абстрактный пример обработки исключения на одном из слое. Возможно нужно было - подобрать немного иную абстракцию.
У DDD подобный подход, и у луковой архитектуры тоже. То есть вышеперечисленные используют подобный общий подход. Думаю Ваше суждение верное, как и если бы сказали, что это DDD - то тоже было бы верно
Отличная статья, хорошие примеры (хотя можно было и побольше) и описание. Полностью поддерживаю автора. Заранее хотелось бы добавить, что для ее понимания для начала надо понять сам SOLID, а уже потом то, что не нужно его везде вставлять. Хочется сделать отсылку к фильму "Всегда говори да".
За опечатку спасибо большое, поправлю, за создание лучше на мой взгляд можно использовать сервис по созданию сущности из которой будет запрос в бд на уникальность например тайтла и уже создание через фабрику(принимает уже валидные данные) сущности
Насчет название и смысла - так может показаться, если прийти к
ValueObjectчерез интуицию(то есть не прибегая к специализированному материалу).Например логика может быть такая: переводится как объект значение - ну тут все понятно)) Пойду кодить)))
Что же касается смысла, причин использования и примеры на мой взгляд интересных реализаций - это можно подсмотреть в книге Вон Верон "Предметно-ориентированное проектирование". Там достаточно подробно это все описано.
Опять же это мое видение.
А что касается конкретного названия - смею предположить, что нужно было как то назвать этот подход и тут
"Объект-значение"в контексте архитектурногоподходаи в контекстесинтаксисавыбранного языка программирование - может означатьразный смысл.В первом случае(
контекст подхода) - этоосмыслениетекущего объекта со стороныбизнес логикиВо втором случае(
контекст синтаксиса ЯП) - можно предположить, как раз таки, что у объекта естькакое то значениеи ни про какую бизнес логику или осмысление тут уже речь не идет.И закончу ответ фразой: "Отвергаешь - предлагай". То есть, какое название с Вашей точки зрения - было бы удачное?
Насчет замечания по поводу исключений - такой подход так же имеет место быть. Я же хотел - как можно максимальнее сосредоточить статью на DTO и VO. Что бы все внимание досталось именно им.
Что же касается - логирования - в текущем контексте - это был лишь инструмент для того, что б показать абстрактный пример обработки исключения на одном из слое. Возможно нужно было - подобрать немного иную абстракцию.
'empty' поправил(убрал) - спасибо, Вы правы)
У DDD подобный подход, и у луковой архитектуры тоже. То есть вышеперечисленные используют подобный общий подход. Думаю Ваше суждение верное, как и если бы сказали, что это DDD - то тоже было бы верно
Отличная статья, хорошие примеры (хотя можно было и побольше) и описание. Полностью поддерживаю автора. Заранее хотелось бы добавить, что для ее понимания для начала надо понять сам SOLID, а уже потом то, что не нужно его везде вставлять. Хочется сделать отсылку к фильму "Всегда говори да".