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

M>Релевантных для задачи никаких.
Это понятно, просто их описание лучше помогло бы мне понять, какая у них семантика.

S>>Как устроен метод sku_item.createObligation(Supplybbligation(Order))?
M>Как реализуешь, так и будет устроен. Может он записи в БД создает, может API вызывает, может в файл складывает.
Это не ответ, а уход от ответа. Очень многие "архитектуры" спотыкаются ровно на том, что при реализации получается чушь, хотя картинка исходно была красивая.

S>>Почему метод вы написали так, а не SupplyObligation.create(sku_item, Order), и не Order.createSupplyObligation(sku_item)?
M>Потому что логика предметной области требует писать именно так. Обязательство это свойство единицы товара, а не самостоятельная сущность и тем более не свойство заказа.
Вот это нужно как-то обосновывать. Потому, что связи не являются "свойствами" в каком-то объективном смысле — они не "принадлежат" сущности.
Вот у нас есть отдел, есть его начальник. "Руководить" — это связь между отделом и сотрудником; она является "свойством" сотрудника в той же степени, что и отдела.
Поэтому и непонятно, отчего вы решили, что обязательство — это "свойство" единицы товара, что бы понятие "единица товара" ни означало.

Вся идея ДДД состоит в том, что архитектура должна проистекать из домена, а не из представления архитектора о прекрасном.
Это понятно. Непонятно, почему вы "поведение" приписываете каким-то конкретным концептам из вашего "домена".
В домене "торговля товаром" обязательство является свойством контрагента, а не какого-то конкретного товара. Это не товар "перемещается" от поставщика к получателю, это кто-то, обладающий свободой воли, перемещает товар.

S>>Как мне гарантировать атомарность резервирования товаров в заказе — либо весь заказ, либо ничего?
M>Как тебе угодно: транзакциями, блокировами, многофазными коммитами, вручную, автоматически или через аспекты. Физическая реализация ортогональна дизайну.
Так не бывает. Дизайн очень сильно влияет на реализацию, ни о какой ортогональности речь идти не может.

M>Что важно, это задуматься действительно ли атомарность нужна по предметной области или это очередная выдуманная хотелка потому что все так делают?
Можно и задуматься, хотя в контексте этого разговора это оффтоп. Оффтоп потому, что предметная область существует объективно. Да, на этапе анализа иКмеет смысл уточнять требования — совершенно необязательно автоматизировать неэффективный процесс, можно сначала его перепроектировать, а уже потом воплощать в коде.
Но рано или поздно мы приходим к тому, что есть некоторые требования. Реализация не должна диктовать требования архитектуре, а архитектура — бизнесу.
Нам нужна такая методология, которая позволяет проектировать архитектуру так, чтобы она одновременно удовлетворяла бизнес-требованиям и позволяла эффективную реализацию.
А не так, что мы делаем архитектуру для "а давайте мы изменим постановку задачи", и потом "наша ортогональная реализация работает за O(N^3), хотя у конкурентов O(logN)".


M>Представь, что у тебя есть вьюха из нескольких таблиц. В классических СУБД она доступна только для чтения. А теперь представь, что ты можешь делать в нее INSERT или UPDATE и эта команда автоматически приведет к изменению исходных таблиц. Дальше представь, что это вьюха маппится на какую-то entity в коде и эта entity ведет себя неотличима от всех остальных маппингов. Вот это и есть проекция. Детали реализации могут быть совершенно любыми, от вьюх и хранимых процедур на уровне БД, до полной иммутабельности на эффектах и соответствующих монадах.
Нет, это не проекция. То, что вы описываете — это REST-идеология, когда все сценарии выражаются в терминах CRUD-операций. Но она сама по себе работает только тогда, когда у нас нет никакого "поведения" за пределами этих модификаций. Вот я взял и добавил связь между сотрудником и департаментом — и это привело к определённому результату, независимо от того, оформил ли я это через department.Employees += e или через e.Deparment = department. А может, так вообще нельзя, и нужно создать экземпляр EmployeeContractAddendum, который после подписания обеими сторонами автоматически отразит изменения штатного расписания департамента и должности у сотрудника.

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

M>Релевантных для задачи никаких.
Это понятно, просто их описание лучше помогло бы мне понять, какая у них семантика.

S>>Как устроен метод sku_item.createObligation(Supplybbligation(Order))?
M>Как реализуешь, так и будет устроен. Может он записи в БД создает, может API вызывает, может в файл складывает.
Это не ответ, а уход от ответа. Очень многие "архитектуры" спотыкаются ровно на том, что при реализации получается чушь, хотя картинка исходно была красивая.

S>>Почему метод вы написали так, а не SupplyObligation.create(sku_item, Order), и не Order.createSupplyObligation(sku_item)?
M>Потому что логика предметной области требует писать именно так. Обязательство это свойство единицы товара, а не самостоятельная сущность и тем более не свойство заказа.
Вот это нужно как-то обосновывать. Потому, что связи не являются "свойствами" в каком-то объективном смысле — они не "принадлежат" сущности.
Вот у нас есть отдел, есть его начальник. "Руководить" — это связь между отделом и сотрудником; она является "свойством" сотрудника в той же степени, что и отдела.
Поэтому и непонятно, отчего вы решили, что обязательство — это "свойство" единицы товара, что бы понятие "единица товара" ни означало.

M>Вся идея ДДД состоит в том, что архитектура должна проистекать из домена, а не из представления архитектора о прекрасном.
Это понятно. Непонятно, почему вы "поведение" приписываете каким-то конкретным концептам из вашего "домена".
В домене "торговля товаром" обязательство является свойством контрагента, а не какого-то конкретного товара. Это не товар "перемещается" от поставщика к получателю, это кто-то, обладающий свободой воли, перемещает товар.

S>>Как мне гарантировать атомарность резервирования товаров в заказе — либо весь заказ, либо ничего?
M>Как тебе угодно: транзакциями, блокировами, многофазными коммитами, вручную, автоматически или через аспекты. Физическая реализация ортогональна дизайну.
Так не бывает. Дизайн очень сильно влияет на реализацию, ни о какой ортогональности речь идти не может.

M>Что важно, это задуматься действительно ли атомарность нужна по предметной области или это очередная выдуманная хотелка потому что все так делают?
Можно и задуматься, хотя в контексте этого разговора это оффтоп. Оффтоп потому, что предметная область существует объективно. Да, на этапе анализа иКмеет смысл уточнять требования — совершенно необязательно автоматизировать неэффективный процесс, можно сначала его перепроектировать, а уже потом воплощать в коде.
Но рано или поздно мы приходим к тому, что есть некоторые требования. Реализация не должна диктовать требования архитектуре, а архитектура — бизнесу.
Нам нужна такая методология, которая позволяет проектировать архитектуру так, чтобы она одновременно удовлетворяла бизнес-требованиям и позволяла эффективную реализацию.
А не так, что мы делаем архитектуру для "а давайте мы изменим постановку задачи", и потом "наша ортогональная реализация работает за O(N^3), хотя у конкурентов O(logN)".


M>Представь, что у тебя есть вьюха из нескольких таблиц. В классических СУБД она доступна только для чтения. А теперь представь, что ты можешь делать в нее INSERT или UPDATE и эта команда автоматически приведет к изменению исходных таблиц. Дальше представь, что это вьюха маппится на какую-то entity в коде и эта entity ведет себя неотличима от всех остальных маппингов. Вот это и есть проекция. Детали реализации могут быть совершенно любыми, от вьюх и хранимых процедур на уровне БД, до полной иммутабельности на эффектах и соответствующих монадах.
Нет, это не проекция. То, что вы описываете — это REST-идеология, когда все сценарии выражаются в терминах CRUD-операций. Но она сама по себе работает только тогда, когда у нас нет никакого "поведения" за пределами этих модификаций. Вот я взял и добавил связь между сотрудником и департаментом — и это привело к определённому результату, независимо от того, оформил ли я это через department.Employees += e или через e.Deparment = department. А может, так вообще нельзя, и нужно создать экземпляр EmployeeContractAddendum, который после подписания обеими сторонами автоматически отразит изменения штатного расписания департамента и должности у сотрудника.