Comments 3
На эту тему уже высказывались очень многие известные люди помимо Фаулера и компании. Тут ведь все зависит от того, какая идея лежит за самим приложением, какая архитектура используется. Например, есть такой подход CQRS. Сам по себе он говорит только о разделении команд и запросов. Но на практике такая система начинает часто сопрягаться с EventQueue и MessageBus и так далее. И как раз в такой системе Anemic (больше нравится «бескровный») Domain Model как раз кстати.
CQRS известна давно и это не ноу-хау последней пятилетки. Просто такие системы сложнее проектировать и поддерживать. Но у них есть своя ниша. Большинству же приложений хватит «стандартного» подхода, т.е. того который описывается у Фаулера. И в этом плане статья очень полезная, так как смешение ответственностей в классах огромная проблема. И решается она только опытом, когда уже начинаешь понимать, что оставить в доменном объекте, а что унести в сервис.
CQRS известна давно и это не ноу-хау последней пятилетки. Просто такие системы сложнее проектировать и поддерживать. Но у них есть своя ниша. Большинству же приложений хватит «стандартного» подхода, т.е. того который описывается у Фаулера. И в этом плане статья очень полезная, так как смешение ответственностей в классах огромная проблема. И решается она только опытом, когда уже начинаешь понимать, что оставить в доменном объекте, а что унести в сервис.
Небольшое замечание по переводу терминологии: всё-таки анемия — это не совсем (я бы даже сказал — совсем не) бледность. Поэтому и переводить надо «анемичная доменная модель».
Sign up to leave a comment.
Anemic Domain Model [Перевод]