Здравствуйте, #John, Вы писали:

J>Здравствуйте, samius, Вы писали:


S>>метод UpdateInformation вероятно будет и в анемике тоже. Ключевой поинт анемика лишь в том, нахрена этот метод нужен User-у? Не отменяя того, что User- агрегат для изменения его информации, можно записать
S>>UpdateInformation(User user, string info, string email),

J>Это процедурный стиль программирования, типы данных отдельно, логика отдельно.
Единственное, что я изменил в этой записи — передал неявный параметр явно и в коде метода придется к полям user-а обращаться с явным указанием, а не с неявным (this.)

J>Объектно ориентированный подход — это когда данные и логика в одном объекте и мы работаем с объекатами.
J>В ОО объекты представляют сущности из реального мира(ограниченные условиями проекта).
J>Напр. хамелеон умеет менять цвет кожи. В коде мы и должны описывать хамелеона:
J>

J>class Chameleon
J>{
J>    public Color skinColor { get; private set; };

J>    public void ChangeSkin(Color color) => skinColor = color; 
J>}
J>

и чем же следующий хамелеон хуже?

class Chameleon
{
    public Color skinColor { get; set; };
}

J>ObjectsAndDataStructures
Не, ну это детский сад какой-то. Я предпочитаю опираться на принципы, сформулированные Кэйем. У него ничего нет про "данные и логика в одном объекте".

S>>Объекты всегда в правильном состоянии для чего? Для какого процесса?
J>Что бы можно было создать/достать из бд агрегат рут, вызвать любой метод и объект был в валидном состоянии, и ни каких ошибок не выкинуло(напр. NRE),
J>что бы агрегат рут без дополнительных проверок, можно было просто взять и сохранить в бд целиком, одной транзакцией, и не получилось что мы потеряли часть данных.

Я о том, когда валидное состояние для одного процесса(активности) подразумевает потерю части данных, необходимых для другого процесса (активности). При большом и все время растущем наборе активностей все данные не могут быть валидными для любых активностей.