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

L>От того, что мы замесим в один класс и хранимые поля, и методы работы с ними, что от этого модель данных начнет меняться чаще?

Представь себе модель данных которая есть сеть == граф, который задан одним из известных способов. Модель примитивная до безобразия.
Теперь начинаем работать над этой сетью для достижения целей кастомера, т.е. выполнять его пожеления.Внезапно оказывается, модель для решения задач меняется постоянно, т.к. кастомер вечно хочет новые вещи, а модель данных прктически не меняется и так и остаётся графом, который задан известным способом.
И вот изредка, когда некоторые задачи требуют иное задание графа с целью получить более выгодную вычислительную сложность, приходится менять и модель данных.
Итого, в наличии две модели — модель данных и модель операций над моделью данных. И в каждой из моделей data structures будут разными. Всего то.

Собственно про это и говорится в DDD

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

L>>От того, что мы замесим в один класс и хранимые поля, и методы работы с ними, что от этого модель данных начнет меняться чаще?

I>Представь себе модель данных которая есть сеть == граф, который задан одним из известных способов. Модель примитивная до безобразия.
I>Теперь начинаем работать над этой сетью для достижения целей кастомера, т.е. выполнять его пожеления.Внезапно оказывается, модель для решения задач меняется постоянно, т.к. кастомер вечно хочет новые вещи, а модель данных прктически не меняется и так и остаётся графом, который задан известным способом.
I>И вот изредка, когда некоторые задачи требуют иное задание графа с целью получить более выгодную вычислительную сложность, приходится менять и модель данных.
I>Итого, в наличии две модели — модель данных и модель операций над моделью данных. И в каждой из моделей data structures будут разными. Всего то.

I>Собственно про это и говорится в DDD

ты сейчас с кем разговаривал? причем тут все это?

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

I>>Собственно про это и говорится в DDD

L>ты сейчас с кем разговаривал? причем тут все это?

"модель данных меняется намного реже модели обработки этих данных" @

Вроде как очевидная фраза а тебя понесло непойми куда

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

L>Или если мы делаем проект, про который мы гарантированно знаем, что модель данных не будет меняться, то что ООП начнет "блистать во всей красе"?

Нужно всего лишь отделять модель данных от модели операций над этими данными. В простейшем случае это можно объединить и в приведеном примере будет

account1.TransferTo(accout2, 100, Currency.USD);

Но когда трансферы усложняются, для этих операций вырастает своя моделька и хранить её вместе с моделью account как то не правильно.

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

I>Итого, в наличии две модели — модель данных и модель операций над моделью данных. И в каждой из моделей data structures будут разными. Всего то.
Ага, вот только остается вопрос: какие классы создавать?

I>Собственно про это и говорится в DDD
Не все, см вопрос выше.

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

L>>Или если мы делаем проект, про который мы гарантированно знаем, что модель данных не будет меняться, то что ООП начнет "блистать во всей красе"?

I>Нужно всего лишь отделять модель данных от модели операций над этими данными. В простейшем случае это можно объединить и в приведеном примере будет
I>

I>account1.TransferTo(accout2, 100, Currency.USD);
I>

I>Но когда трансферы усложняются, для этих операций вырастает своя моделька и хранить её вместе с моделью account как то не правильно.

Поздравляю, ты тоже сторонник процедурного подхода.

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

I>>Итого, в наличии две модели — модель данных и модель операций над моделью данных. И в каждой из моделей data structures будут разными. Всего то.
G>Ага, вот только остается вопрос: какие классы создавать?

Классы в зависимости от функций каждой модели.

I>>Собственно про это и говорится в DDD
G>Не все, см вопрос выше.

Про классы — говорится.

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

L>>ты сейчас с кем разговаривал? причем тут все это?

I>"модель данных меняется намного реже модели обработки этих данных" @

I>Вроде как очевидная фраза а тебя понесло непойми куда

Это тебя понесло непойми куда. Прочитай определение уже и пойми, что твое разделение модели данных и кода обработки ее и есть уход от ООП в его классичесом определении ("data structures consisting of data fields and methods together with their interactions").

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

I>>Нужно всего лишь отделять модель данных от модели операций над этими данными. В простейшем случае это можно объединить и в приведеном примере будет
I>>

I>>account1.TransferTo(accout2, 100, Currency.USD);
I>>

I>>Но когда трансферы усложняются, для этих операций вырастает своя моделька и хранить её вместе с моделью account как то не правильно.

L>Поздравляю, ты тоже сторонник процедурного подхода.

Я сторонник разделения мух и котлет.

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

I>>>Но когда трансферы усложняются, для этих операций вырастает своя моделька и хранить её вместе с моделью account как то не правильно.

L>>Поздравляю, ты тоже сторонник процедурного подхода.

I>Я сторонник разделения мух и котлет.

Да, и отход от ООП в его классическом определении очень способствует этому.

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

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

I>>>Итого, в наличии две модели — модель данных и модель операций над моделью данных. И в каждой из моделей data structures будут разными. Всего то.
G>>Ага, вот только остается вопрос: какие классы создавать?

I>Классы в зависимости от функций каждой модели.

То есть сделать кучу "параллельных" моделей, поддерживать синхронно изменения, перекладывать данные туда-сюда постоянно?

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

L>Это тебя понесло непойми куда. Прочитай определение уже и пойми, что твое разделение модели данных и кода обработки ее и есть уход от ООП в его классичесом определении ("data structures consisting of data fields and methods together with their interactions").

А что если data structure будет иметь вот такой вид:

Account _account;
ICurrencyRates _rates;
ITransferPolicy _policy;

Добавив сюда метод Transfer и дав всему этому название TransferService получим ровно то что в классическом определении.

Или ты считаешь, что data structure может состоять только из примитивных типов ?

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

I>>Я сторонник разделения мух и котлет.

L>Да, и отход от ООП в его классическом определении очень способствует этому.

Я считаю что SOLID == OOP. Потому можно разделять сколько угодно и как угодно.

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

I>>>>Итого, в наличии две модели — модель данных и модель операций над моделью данных. И в каждой из моделей data structures будут разными. Всего то.
G>>>Ага, вот только остается вопрос: какие классы создавать?

I>>Классы в зависимости от функций каждой модели.

G>То есть сделать кучу "параллельных" моделей, поддерживать синхронно изменения, перекладывать данные туда-сюда постоянно?

Зачем перекладывать ? Модель данных и модель операций — это значит что данных отдельно от операций над ними. Всё. Модель операций может вообще не иметь состояния. Но даже если и имеет, это далеко не всегда значит, что будут какие то параллельные модели где надо синхронизировать изменения.

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

L>>Это тебя понесло непойми куда. Прочитай определение уже и пойми, что твое разделение модели данных и кода обработки ее и есть уход от ООП в его классичесом определении ("data structures consisting of data fields and methods together with their interactions").

I>А что если data structure будет иметь вот такой вид:

I>

I>Account _account;
I>ICurrencyRates _rates;
I>ITransferPolicy _policy;
I>

I>Добавив сюда метод Transfer и дав всему этому название TransferService получим ровно то что в классическом определении.

Я не знаю ни что такое Account, ни что такое ICurrencyRates, ни что такое ITransferPolicy.

I>Или ты считаешь, что data structure может состоять только из примитивных типов ?

1. Что такое "примитивные типы"?
2. С чего вы это взяли, что я так считаю?
3. Какое это имеет отношение в тому, что обсуждается?

P.S. Вы не могли бу проямнить свою позицию, чтобы я понимал, что именно вы отстаиваете?

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

L>>Да, и отход от ООП в его классическом определении очень способствует этому.

I>Я считаю что SOLID == OOP. Потому можно разделять сколько угодно и как угодно.

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

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

I>>А что если data structure будет иметь вот такой вид:

I>>

I>>Account _account;
I>>ICurrencyRates _rates;
I>>ITransferPolicy _policy;
I>>

I>>Добавив сюда метод Transfer и дав всему этому название TransferService получим ровно то что в классическом определении.
L>Я не знаю ни что такое Account, ни что такое ICurrencyRates, ни что такое ITransferPolicy.

Account это entity, например такие классы генерит EF ICurrencyRates это конвертор курсов, нужен для перевода средств со счета на счет если у счетов разные валюты. ITrancferPolicy это правила которые определяют как происходит конкретный трансфер.

I>>Или ты считаешь, что data structure может состоять только из примитивных типов ?

L>1. Что такое "примитивные типы"?

int, string, double

L>2. С чего вы это взяли, что я так считаю?

Потому что один раз ты назвал такой подход "менее ооп"

L>3. Какое это имеет отношение в тому, что обсуждается?

Непосредственное.

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

I>>>

I>>>Account _account;
I>>>ICurrencyRates _rates;
I>>>ITransferPolicy _policy;
I>>>

I>>>Добавив сюда метод Transfer и дав всему этому название TransferService получим ровно то что в классическом определении.
L>>Я не знаю ни что такое Account, ни что такое ICurrencyRates, ни что такое ITransferPolicy.

I>Account это entity, например такие классы генерит EF ICurrencyRates это конвертор курсов, нужен для перевода средств со счета на счет если у счетов разные валюты. ITrancferPolicy это правила которые определяют как происходит конкретный трансфер.

Что Account делает в полях сервиса? Зачем он там?

I>>>Или ты считаешь, что data structure может состоять только из примитивных типов ?

L>>1. Что такое "примитивные типы"?

I>int, string, double

Ок.

L>>2. С чего вы это взяли, что я так считаю?

I>Потому что один раз ты назвал такой подход "менее ооп"

При чем тут подход? С спрашивал "с чего вы взяли, что я считаю, что data structure может состоять только из примитивных типов"?

L>>3. Какое это имеет отношение в тому, что обсуждается?

I>Непосредственное.

Значит вам не составит труда продемострировать это отношение. Дерзайте.

P.S. Вы не могли бу проямнить свою позицию, чтобы я понимал, что именно вы отстаиваете?

L>Более того, очень многими неглупыми людьми ставится под сомнение его полезность. Все народ от того же насквозь оопшного DDD плюется, а вот вполне из себя процедурный anemic model вызывает массу положительных эмоций.

Вас кто-то обманул. DDD и anemic model — перпендикулярные концепции. Вполне могут жить друг с другом, хотя бы потому, что DDD — не "насквозь оопшный" подход. Более того, они часто живут друг с другом — для этого в DDD придуман слой бизнес-логики.

L>Это тебя понесло непойми куда. Прочитай определение уже и пойми, что твое разделение модели данных и кода обработки ее и есть уход от ООП в его классичесом определении ("data structures consisting of data fields and methods together with their interactions").
Вообще-то никакого ухода от ООП здесь нет. Логика, затрагивающая несколько сущностей, не обязательно должна быть инкапсулирована в одной из них. Вполне нормально, когда она инкапуслирована в каком-то контексте. Пример: два объекта класса "Человек" судятся друг с другом. Нельзя определить операцию "податьВСуд" для класса "Человек", потому что суд руководствуется законом. DDD в таких случаях предлагает в слое бизнес-логики создать класс "Суд" с методом "рассудить(Человек истец, Человек ответчик)" и инициализировать его экземпляр сводом законов.