Агрегат — это сущность, которая представлена несколькими объектами в памяти и, часто, хранится в нескольких таблицах. С такими сущностями нужно работать специальным образом (менять в рамках транзакции, ссылаться только на сам агрегат, а не на вложенные сущности и т.д.)
Воувоу, сумма заказа передается в конструкторе? Сумма заказа обычно рассчитывается, причем по довольно сложным правилам. И у нее есть определенные моменты пересчета (и совсем не обязательно, чтобы это был момент установки какого-то свойства).
Тема холиварная, конечно. Анемичная модель удобна для сервис-ориентированных stateless приложений, т.к. anemic легче сделать стейтлесс. Принципиальной разницы нету, вообще.
В сервисах описать, да. ООП в сервисах есть, разве что наследование не используется широко. Или, по-вашему, ООП это только когда мы пишем order.Save() вместо orderService.Save(order)?
Если принять, что фреймворк влияет в том числе на дизайн приложения, то, например, в первых версиях Entity Framework нужно было наследоваться от классов фреймворка, использовать только сгенерированный код, использовать edmx, использовать unit of work. В смысле ограничений весьма сильно.
Хороший ОРМ (для дотнета, например, linq2db, бывший bl toolkit) — библиотека, плохой — фреймворк (пример — первые версии entity framework, linq 2 sql).
А вот продажникам урежут зарплаты или уберут премии. Вопрос: за что?
Сорри, что отвечаю на каждую вашу реплику.
Суть работы продажника и программиста разная. Внутренняя мотивация разная. Аналог продажника у программистов — это product owner, продакт-менеджер, и его доход (обычно премии) привязаны к продажам.
Программист же в продуктовой компании напрямую влиять на продукт не может, он делает то, что ему сказали делать на этой неделе. Сказали "все фиксим баги" — все сидим и фиксим, сказали воплощать обещания маркетологов — значит, не фиксим, добавляем новый функционал (а с ним и баги).
То есть, по сути, баги в продукте — это не вина программиста. Без багов разрабатывать невозможно (хотя можно выдавать код в среднем более качественный, но дороже), а стабильность продукта сильно зависит от времени на тестирование и починку ошибок.
Они страдают зависимостью от продукта. И конкретно в этом и заключается проблема. Почему только зарплата продажника зависит от качества продукта и того, как он продается, а других работников — нет?
Программисты лажают с фичами, маркетологи дают невыполнимые обещания, менеджеры ставят невыполнимые сроки, пользователи, гады, не хотят пользоваться.
Невозможно все контролировать, невозможно отвечать за все и все делать самому. Делегация и разделение — это суть бизнеса, и все работники должны это принимать и работать исходя из этого.
Лучше без KPI, если компания не жадная(% с продаж, например), а то можно увлечься и очень легко накидать таких KPI, что сотрудники начнут хакать эти самые KPI, сводя всю деятельность к «полезной», т.е. только той, которая улучшает показатели KPI.
Согласен. Главное не забыть, что задача KPI — это повышение эффективности компании, а не экономия по три копейки с сотрудника по каждому поводу.
Описание бизнес-процессов в формальном виде хорошая вещь...
Хорошая, но не всегда нужная. Делать бизнес-анализ и описание процессов без четкой цели бессмысленно. Нужна причина.
Обычные причины — это обучение новых сотрудников, налаживание управленческого учета (часто если есть подозрение, что некто очень хитрый перераспределяет блага в свою пользу).
Также описание и анализ бизнес-процессов нужны для автоматизации
Не уверен, что KPI и бизнес-процессы это одно и то же.
Бинес-процессы описывают "алгоритм" функионирования бизнеса: какие действия в каком случае кем совершаются, кто ответственный, что делать в случае "исключительных" ситуаций и т.п.
Формализация (описание) бизнес процессов в общем-то не предназначена для оценки или увеличения эффективности бизнеса (и отдельных людей), а больше для увеличения "прозрачности" и "ясности" каждого этапа, и выявления возможных "тупиковых ответвлений", не предусмотренных и не продуманных заранее.
Агрегат — это сущность, которая представлена несколькими объектами в памяти и, часто, хранится в нескольких таблицах. С такими сущностями нужно работать специальным образом (менять в рамках транзакции, ссылаться только на сам агрегат, а не на вложенные сущности и т.д.)
Вот это, на мой взгляд, довольно спорное утверждение. Правильнее было бы сказать, что изменение агрегата должно обязательно происходить в транзакции.
Воувоу, сумма заказа передается в конструкторе? Сумма заказа обычно рассчитывается, причем по довольно сложным правилам. И у нее есть определенные моменты пересчета (и совсем не обязательно, чтобы это был момент установки какого-то свойства).
Тема холиварная, конечно. Анемичная модель удобна для сервис-ориентированных stateless приложений, т.к. anemic легче сделать стейтлесс. Принципиальной разницы нету, вообще.
В сервисах описать, да. ООП в сервисах есть, разве что наследование не используется широко. Или, по-вашему, ООП это только когда мы пишем
order.Save()вместоorderService.Save(order)?Любую бизнес-логику можно описать и при помощи rich model, и при помощи anemic model.
Поддержу.
Rich model vs Anemic Model — это деталь реализации, со своими достоинствами и недостатками.
Хмм, а разве DDD это про реализацию? Сервисную или веб архитектуру удобно делать анемичной, чтобы не хранить состояние.
Спасибо за статью.
Было бы интересно почитать про выражение и преобразование концептуальной архитектуры в код.
Если принять, что фреймворк влияет в том числе на дизайн приложения, то, например, в первых версиях Entity Framework нужно было наследоваться от классов фреймворка, использовать только сгенерированный код, использовать edmx, использовать unit of work. В смысле ограничений весьма сильно.
В дотнете фреймворк — это джит-компилятор и рантайм. Остальное — это библиотеки.
Фреймворк вызывает ваш код, ваш код вызывает библиотеки.
Хороший ОРМ (для дотнета, например, linq2db, бывший bl toolkit) — библиотека, плохой — фреймворк (пример — первые версии entity framework, linq 2 sql).
Это вы зря, про простую задачу. DSL или строки с форматированием самое то.
Сорри, что отвечаю на каждую вашу реплику.
Суть работы продажника и программиста разная. Внутренняя мотивация разная. Аналог продажника у программистов — это product owner, продакт-менеджер, и его доход (обычно премии) привязаны к продажам.
Программист же в продуктовой компании напрямую влиять на продукт не может, он делает то, что ему сказали делать на этой неделе. Сказали "все фиксим баги" — все сидим и фиксим, сказали воплощать обещания маркетологов — значит, не фиксим, добавляем новый функционал (а с ним и баги).
То есть, по сути, баги в продукте — это не вина программиста. Без багов разрабатывать невозможно (хотя можно выдавать код в среднем более качественный, но дороже), а стабильность продукта сильно зависит от времени на тестирование и починку ошибок.
Потому что иначе он будет продавать плохо.
Программисты лажают с фичами, маркетологи дают невыполнимые обещания, менеджеры ставят невыполнимые сроки, пользователи, гады, не хотят пользоваться.
Невозможно все контролировать, невозможно отвечать за все и все делать самому. Делегация и разделение — это суть бизнеса, и все работники должны это принимать и работать исходя из этого.
Согласен. Главное не забыть, что задача KPI — это повышение эффективности компании, а не экономия по три копейки с сотрудника по каждому поводу.
Хорошая, но не всегда нужная. Делать бизнес-анализ и описание процессов без четкой цели бессмысленно. Нужна причина.
Обычные причины — это обучение новых сотрудников, налаживание управленческого учета (часто если есть подозрение, что некто очень хитрый перераспределяет блага в свою пользу).
Также описание и анализ бизнес-процессов нужны для автоматизации
Не уверен, что KPI и бизнес-процессы это одно и то же.
Бинес-процессы описывают "алгоритм" функионирования бизнеса: какие действия в каком случае кем совершаются, кто ответственный, что делать в случае "исключительных" ситуаций и т.п.
Формализация (описание) бизнес процессов в общем-то не предназначена для оценки или увеличения эффективности бизнеса (и отдельных людей), а больше для увеличения "прозрачности" и "ясности" каждого этапа, и выявления возможных "тупиковых ответвлений", не предусмотренных и не продуманных заранее.
Скажите, на каком-нибудь из приведенных вами сайтов можно заказать приложение за рассчитанную там цену?
Статья понравилась спасибо.
Ну как же, человек пришел за большими деньгами, а вы его работать заставляете. [sarcasm]