методы в объектах DDD по сравнению с сервисами
Наша команда довольно плохо знакома с DDD и пытается реализовать некоторые понятия в нашем текущем проекте. Один вопрос, который подошел, состоит в том, поместить ли методы в объекты объекта или объекты службы.
Некоторые члены команды чувствуют, что объекты должны только содержать значения, и вся функциональность должна содержаться в сервисах. Другие чувствуют, что это делает объекты объекта анемичными, и что они должны содержать функциональность, которая касается объекта, в то время как объекты службы должны быть использованы для большей сквозной функциональности.
Мы задаемся вопросом, что формальная точка зрения DDD находится на этом, а также что работало на людей в реальной жизни.
1 ответ
Я слышал о вещах, таких как Ehcache, но кажется довольно тяжелым весом для того, что мне нужно, и я не уверен, достаточно ли достаточно для моего приложения (запоминание, что решение не может быть значительно медленнее, чем хесмап).
Я действительно не знаю, можно ли сказать, что Ehcache - тяжелый вес. По крайней мере, я не считаю Ehcache как таковой, особенно при использовании магазина памяти (который поддерживается расширенным LinkedHashmap и, конечно, является самым быстрым вариантом кэширования). Вы должны попробовать.
Нет формальной точки зрения для DDD, но вся цель богатого модели Domaim - избегать модели модели анемии , так что явно отказывается отдать какое-либо поведение На доменных объектах идет против этого духа.
Одним из школ мышли владеет, что доменные объекты должны быть PoCos / Pojos, что означает, что они не должны содержать абстрактные услуги в качестве членов. Однако это не значит, что они не могут иметь методы, которые взаимодействуют с такими службами.
Чем больше (соответствующее) поведение вы можете дать каждому объекту домена, тем лучше.