Когда я учился в институте, у меня просили списать только те, которым это в длительной перспективе не помогло бы. То есть было видно, что человек не освоит специальность на уровне достаточном, чтобы составить конкуренцию.
А те, кто был на одном уровне знаний (не важно, низком, или высоком) списать не просили.
На западе ИМХО такое отношение к списыванию не из-за конкуренции, а из-за отношения к ценности чужого труда.
Эффективные менеджеры и маркетологи пришли к нам из западной культуры, именно поэтому они смотрятся здесь как нелепый и безжизненный сюрреализм.
Потому что их задача — не "смотреться". Были бы они бесполезны — их бы не было.
По-сути весь смысл западной «толерантности» — во лжи. Все друг-другу лгут о том как они друг-друга любят и дружно делают вид что так оно и есть. Потом приходят домой и пишут на форумах о том как бы они сжигали представителей других национальностей и за что.
Ложная дихотомия, какая прелесть. Плохо — это призывать к вражде против других национальностей. Улыбаешься ты при этом, или хамишь — не важно.
Вообще много есть способов, это и интересные проекты, и важные для человека привилегии (плавающий график, условия труда (отдельный кабинет и т.п.), возможность заниматься своими проектами, подработки и совмещения, карьерный рост и так далее.
Но все это работает на 5, максимум 10% разницы в зарплате.
Цвет и объем памяти, если уж на то пошло, надо выделять в объект-значение.
Сущность — это то, что имеет идентичность, которая не выражается через его данные (сложно сказано).
То есть, если есть сущность клиент, то может быть два Ивана Петрова мужчина холост 65 года рождения, которые, тем не менее, разные.
Объект-значение, напротив, имеет идентичность, выражаемую через его данные. Например, объем памяти 128МВ имеет два атрибута — объем — 128 и единицы измерения (мегабайты). И два значения являются одинаковыми, если у них совпадает объем и единицы измерения.
Агрегат — это сущность, которая представлена несколькими объектами в памяти и, часто, хранится в нескольких таблицах. С такими сущностями нужно работать специальным образом (менять в рамках транзакции, ссылаться только на сам агрегат, а не на вложенные сущности и т.д.)
Воувоу, сумма заказа передается в конструкторе? Сумма заказа обычно рассчитывается, причем по довольно сложным правилам. И у нее есть определенные моменты пересчета (и совсем не обязательно, чтобы это был момент установки какого-то свойства).
Тема холиварная, конечно. Анемичная модель удобна для сервис-ориентированных stateless приложений, т.к. anemic легче сделать стейтлесс. Принципиальной разницы нету, вообще.
В сервисах описать, да. ООП в сервисах есть, разве что наследование не используется широко. Или, по-вашему, ООП это только когда мы пишем order.Save() вместо orderService.Save(order)?
Если принять, что фреймворк влияет в том числе на дизайн приложения, то, например, в первых версиях Entity Framework нужно было наследоваться от классов фреймворка, использовать только сгенерированный код, использовать edmx, использовать unit of work. В смысле ограничений весьма сильно.
И, главное, доказали же — можем, сами все можем! Кору будем есть, но на Солнце полетим.
Когда я учился в институте, у меня просили списать только те, которым это в длительной перспективе не помогло бы. То есть было видно, что человек не освоит специальность на уровне достаточном, чтобы составить конкуренцию.
А те, кто был на одном уровне знаний (не важно, низком, или высоком) списать не просили.
На западе ИМХО такое отношение к списыванию не из-за конкуренции, а из-за отношения к ценности чужого труда.
Думаю, дело не в рычагах контроля. Раньше было то же самое, только никто ничего не знал.
Потому что их задача — не "смотреться". Были бы они бесполезны — их бы не было.
Ложная дихотомия, какая прелесть. Плохо — это призывать к вражде против других национальностей. Улыбаешься ты при этом, или хамишь — не важно.
А рейт какой был?
И, главное, это все — совсем, совсем ни за что, ни про что.
Потому что появляется инструмент давления на людей. Воровство могут и припомнить при случае.
Я согласен, это сарказм был :)
Вообще много есть способов, это и интересные проекты, и важные для человека привилегии (плавающий график, условия труда (отдельный кабинет и т.п.), возможность заниматься своими проектами, подработки и совмещения, карьерный рост и так далее.
Но все это работает на 5, максимум 10% разницы в зарплате.
Например, пообещать (и выплатить) в конце бонус. Но если денег вообще нет, а надо удержать, тогда шантаж, угрозы, лесть.
Еще можно заложников взять, заодно на офис-менеджерах сэкономить.
Цвет и объем памяти, если уж на то пошло, надо выделять в объект-значение.
Сущность — это то, что имеет идентичность, которая не выражается через его данные (сложно сказано).
То есть, если есть сущность клиент, то может быть два Ивана Петрова мужчина холост 65 года рождения, которые, тем не менее, разные.
Объект-значение, напротив, имеет идентичность, выражаемую через его данные. Например, объем памяти
128МВимеет два атрибута — объем — 128 и единицы измерения (мегабайты). И два значения являются одинаковыми, если у них совпадает объем и единицы измерения.Агрегат — это сущность, которая представлена несколькими объектами в памяти и, часто, хранится в нескольких таблицах. С такими сущностями нужно работать специальным образом (менять в рамках транзакции, ссылаться только на сам агрегат, а не на вложенные сущности и т.д.)
Вот это, на мой взгляд, довольно спорное утверждение. Правильнее было бы сказать, что изменение агрегата должно обязательно происходить в транзакции.
Воувоу, сумма заказа передается в конструкторе? Сумма заказа обычно рассчитывается, причем по довольно сложным правилам. И у нее есть определенные моменты пересчета (и совсем не обязательно, чтобы это был момент установки какого-то свойства).
Тема холиварная, конечно. Анемичная модель удобна для сервис-ориентированных stateless приложений, т.к. anemic легче сделать стейтлесс. Принципиальной разницы нету, вообще.
В сервисах описать, да. ООП в сервисах есть, разве что наследование не используется широко. Или, по-вашему, ООП это только когда мы пишем
order.Save()вместоorderService.Save(order)?Любую бизнес-логику можно описать и при помощи rich model, и при помощи anemic model.
Поддержу.
Rich model vs Anemic Model — это деталь реализации, со своими достоинствами и недостатками.
Хмм, а разве DDD это про реализацию? Сервисную или веб архитектуру удобно делать анемичной, чтобы не хранить состояние.
Спасибо за статью.
Было бы интересно почитать про выражение и преобразование концептуальной архитектуры в код.
Если принять, что фреймворк влияет в том числе на дизайн приложения, то, например, в первых версиях Entity Framework нужно было наследоваться от классов фреймворка, использовать только сгенерированный код, использовать edmx, использовать unit of work. В смысле ограничений весьма сильно.