Правила (условия) изменения состояния сущностей можно хранить в спецификациях, проверять их в сервисах, а собственно изменения производить в сущностях, вызывая их методы (не тупо сеттеры, а с семантикой бизнес-процессов, не order.setStatus(STATUS_CANCEL), а order.cancel()) из этих сервисов, при условии соответствия сущности спецификации.
Подскажите, а есть ли какая-нибудь адекватная механика экспорта данных из Kibana? Для задачи вида: есть у нас сохраненный поиск по индексу MyLogIndex с фильтром MySuperEvent и хочу я выгрузить все данные за вчера, например.
То, что вы написали мне прекрасно понятно, однако на практике бизнес может придумать такое количество интересных правил изменения состояния сущности, что держать их все в рамках самой модели есть нарушать все принципы.
И чем лучше передача стратегии с логикой изменения состояния чем просто изменение состояния извне? Или я неправильно понял про стратегии в данном контексте?
Т.е. вот у нас есть Order. Бизнес начинает придумывать разные хитрые правила изменения состояния заказа в зависимости от погоды, дня недели и цвета чулок Марьиванны. Куда мы пихнем эти правила? Куда-то наверх. При этом модель будет анемичной, IOrderProcessingService будет являться фасадом, а внутрях у ней неонка с фабриками, стратегиями, репозиториями марьиванн, хитрыми пайплайнами и прочими классными шаблонами.
Веб-не веб в том разница, что в веб приложении мы вряд ли будем использовать какую-то событийную модель и реакции одних сущностей на изменения состояния других. Т.е. в вебе пайплайн.
Хмм а что мешает иметь еще слои абстракции над анемичной моделью, но под «сервисами»? Все же, я лично воспринимаю «сервисы» как фасады, реализующие некоторый контракт. Ничто не мешает иметь под капотом ООП по госту.
Я не очень согласен в вашим определением «сервисов + анемичной модели».
Мне это все видится скорее как:
Сервисы (фасады) -> некоторая объектная модель с логикой ->
анемичная модель (сущности) как способ хранить состояние. Возможно, с примитивной логикой в рамках одной сущности
Это то, как лично у меня получается жить в современном ынтырпрайзе с ORM/DDD и прочими штуками. Да, это не кошерное ООП, но оно работает в вебе. There is no silver bullet, все дела.
А у вас в веб-приложения прям таки «бохатая модель» везде? Я хотел бы на это посмотреть.
У меня лично (может я и горе-проектировщик, конечно) в контексте больших постоянно развивающихся ASP.NET MVC приложений нормально уживаются именно сервисы с логикой + анемичная модель.
В небольших приложениях (особенно НЕ веб) с ограниченной, заранее ясной бизнес-логикой хорошо взлетает «бохатая модель»/DDD/SOLID/ООП и прочие радости.
Научите меня как строить крупные ынтырпрайз веб приложения с постоянно меняющейся бизнес-логикой на основе Rich Data (Domain?) Model. Книжки, статьи, примеры. Спасибо.
Так в том и дело, что если патч поставить, то производительность упадет. В случае с железным сервером чисто под СУБД можно обойтись без патча, а в случае с виртуалкой — нет.
Выдающийся — это Саша Пушкин с двойкой по математике. А быть отличником в школе не есть что-то выдающееся. Скорее, напротив: человек под напором обстоятельств (родители, «путевка в жизнь», льготы какие-то, инерция) вынужден учить все подряд на 5, хотя ему в принципе не могут быть все предметы интересны.
Нельзя добиться выдающихся результатов в чем-либо без концентрации усилий на этом. Если же у вас по всем предметам «успехи», то, скорее всего, планка слишком низкая.
С этим подходом согласен
И чем лучше передача стратегии с логикой изменения состояния чем просто изменение состояния извне? Или я неправильно понял про стратегии в данном контексте?
Т.е. вот у нас есть Order. Бизнес начинает придумывать разные хитрые правила изменения состояния заказа в зависимости от погоды, дня недели и цвета чулок Марьиванны. Куда мы пихнем эти правила? Куда-то наверх. При этом модель будет анемичной, IOrderProcessingService будет являться фасадом, а внутрях у ней неонка с фабриками, стратегиями, репозиториями марьиванн, хитрыми пайплайнами и прочими классными шаблонами.
Веб-не веб в том разница, что в веб приложении мы вряд ли будем использовать какую-то событийную модель и реакции одних сущностей на изменения состояния других. Т.е. в вебе пайплайн.
Мне это все видится скорее как:
Сервисы (фасады) -> некоторая объектная модель с логикой ->
анемичная модель (сущности) как способ хранить состояние. Возможно, с примитивной логикой в рамках одной сущности
Это то, как лично у меня получается жить в современном ынтырпрайзе с ORM/DDD и прочими штуками. Да, это не кошерное ООП, но оно работает в вебе. There is no silver bullet, все дела.
У меня лично (может я и горе-проектировщик, конечно) в контексте больших постоянно развивающихся ASP.NET MVC приложений нормально уживаются именно сервисы с логикой + анемичная модель.
В небольших приложениях (особенно НЕ веб) с ограниченной, заранее ясной бизнес-логикой хорошо взлетает «бохатая модель»/DDD/SOLID/ООП и прочие радости.
Научите меня как строить крупные ынтырпрайз веб приложения с постоянно меняющейся бизнес-логикой на основе Rich Data (Domain?) Model. Книжки, статьи, примеры. Спасибо.
Но если кто-то гоняет PostgreSQL на виртуалках?
Нельзя добиться выдающихся результатов в чем-либо без концентрации усилий на этом. Если же у вас по всем предметам «успехи», то, скорее всего, планка слишком низкая.