Домен-ориентированный дизайн: избегание анемичных доменов и моделирование реальных ролей

Я ищу несколько советов о том, насколько я должен быть обеспокоен, избегая модели анемичной области. Мы только начинаем работу над DDD и боремся с параличом анализа простых проектных решений. Последнее, на что мы обращаем внимание, - это место, где принадлежит определенная бизнес-логика, например, у нас есть объект Order , который имеет такие свойства, как Status и т. Д. Теперь предположим, что я должен выполнить команду типа UndoLastStatus из-за того, что кто-то допустил ошибку с заказом, это не так просто, как просто изменить Статус , поскольку другая информация должна регистрироваться, а свойства изменены. Теперь в реальном мире это чисто административная задача. На мой взгляд, у меня есть два варианта, о которых я могу думать:

• Вариант 1: Добавить метод в заказ, например, Order.UndoLastStatus () , хотя это имеет смысл, но это не так. т действительно отражают домен. Также Заказ является основным объектом в системе, и если все, что связано с заказом, будет помещено в класс заказа, все может выйти из-под контроля.

• Вариант 2: Создайте объект Магазин , и при этом иметь разные службы, которые представляют разные роли. Так что у меня могут быть Shop.AdminService , Shop.DispatchService и Shop.InventoryService . Так что в этом случае у меня был бы Магазин.AdminService.UndoLastStatus (заказ) .

Теперь у нас есть второй вариант, который гораздо больше отражает предметную область и позволит разработчикам поговорить с бизнес-экспертами о подобных ролях, которые действительно существуют. Но он также движется к анемичной модели. Как вообще было бы лучше пойти?