Сообщение Re[4]: DDD для небольших проектов. от 14.02.2020 8:12
Изменено 14.02.2020 8:18 MadHuman
Re[4]: DDD для небольших проектов.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Poopy Joe, Вы писали:
PJ>>При этом модель должна быть непротиворечивой и все типы всегда валидны, следуя принципу make invalid state unrepresentable. Вот это и будет твоя модель — внутренний круг онион-архитектуры.
S>Утопический принцип. Валидность состояния — это миф. Она имеет место только в рамках конкретного сценария. Вот, скажем, заказ в состоянии "новый" вполне может содержать в себе позиции, которых нет на складе. Ну, нету и нету.
S>А вот, например, зарезервировать заказ можно только в том случае, если всё заказанное готово к резерву.
S>Опять же — в состоянии "новый" заказ может не иметь данных о покупателе, но для того, чтобы сделать его "оплаченным" эти данные необходимы.
S>Чтобы перевести его в статус "в доставке" нам нужно иметь в заказе не просто адрес доставки, а адрес, распознанный нашим шиппинг-партнёром.
S>Как вы собираетесь описывать все эти ограничения при помощи системы типов?
на самом деле есть возможности. посмотрите например (там на F# правда, на C# так изящно неполучится, точнее можно — но это уже будет не так удобно, и даже настолько неудобно что плюсы начнут теряться).
https://www.youtube.com/watch?v=Up7LcbGZFuo
или это https://www.youtube.com/watch?v=1pSH8kElmM4
есть ещё на русском, там другой неплохой пример рассматривается, но суть таже.
S>Здравствуйте, Poopy Joe, Вы писали:
PJ>>При этом модель должна быть непротиворечивой и все типы всегда валидны, следуя принципу make invalid state unrepresentable. Вот это и будет твоя модель — внутренний круг онион-архитектуры.
S>Утопический принцип. Валидность состояния — это миф. Она имеет место только в рамках конкретного сценария. Вот, скажем, заказ в состоянии "новый" вполне может содержать в себе позиции, которых нет на складе. Ну, нету и нету.
S>А вот, например, зарезервировать заказ можно только в том случае, если всё заказанное готово к резерву.
S>Опять же — в состоянии "новый" заказ может не иметь данных о покупателе, но для того, чтобы сделать его "оплаченным" эти данные необходимы.
S>Чтобы перевести его в статус "в доставке" нам нужно иметь в заказе не просто адрес доставки, а адрес, распознанный нашим шиппинг-партнёром.
S>Как вы собираетесь описывать все эти ограничения при помощи системы типов?
на самом деле есть возможности. посмотрите например (там на F# правда, на C# так изящно неполучится, точнее можно — но это уже будет не так удобно, и даже настолько неудобно что плюсы начнут теряться).
https://www.youtube.com/watch?v=Up7LcbGZFuo
или это https://www.youtube.com/watch?v=1pSH8kElmM4
есть ещё на русском, там другой неплохой пример рассматривается, но суть таже.
Re[4]: DDD для небольших проектов.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Poopy Joe, Вы писали:
PJ>>При этом модель должна быть непротиворечивой и все типы всегда валидны, следуя принципу make invalid state unrepresentable. Вот это и будет твоя модель — внутренний круг онион-архитектуры.
S>Утопический принцип. Валидность состояния — это миф. Она имеет место только в рамках конкретного сценария. Вот, скажем, заказ в состоянии "новый" вполне может содержать в себе позиции, которых нет на складе. Ну, нету и нету.
S>А вот, например, зарезервировать заказ можно только в том случае, если всё заказанное готово к резерву.
S>Опять же — в состоянии "новый" заказ может не иметь данных о покупателе, но для того, чтобы сделать его "оплаченным" эти данные необходимы.
S>Чтобы перевести его в статус "в доставке" нам нужно иметь в заказе не просто адрес доставки, а адрес, распознанный нашим шиппинг-партнёром.
S>Как вы собираетесь описывать все эти ограничения при помощи системы типов?
на самом деле есть возможности. посмотрите например (там на F# правда, на C# так изящно неполучится, точнее можно — но это уже будет не так удобно, и даже настолько неудобно что плюсы начнут теряться).
https://www.youtube.com/watch?v=Up7LcbGZFuo
или это
https://youtu.be/Bn132AtZLhc
S>Здравствуйте, Poopy Joe, Вы писали:
PJ>>При этом модель должна быть непротиворечивой и все типы всегда валидны, следуя принципу make invalid state unrepresentable. Вот это и будет твоя модель — внутренний круг онион-архитектуры.
S>Утопический принцип. Валидность состояния — это миф. Она имеет место только в рамках конкретного сценария. Вот, скажем, заказ в состоянии "новый" вполне может содержать в себе позиции, которых нет на складе. Ну, нету и нету.
S>А вот, например, зарезервировать заказ можно только в том случае, если всё заказанное готово к резерву.
S>Опять же — в состоянии "новый" заказ может не иметь данных о покупателе, но для того, чтобы сделать его "оплаченным" эти данные необходимы.
S>Чтобы перевести его в статус "в доставке" нам нужно иметь в заказе не просто адрес доставки, а адрес, распознанный нашим шиппинг-партнёром.
S>Как вы собираетесь описывать все эти ограничения при помощи системы типов?
на самом деле есть возможности. посмотрите например (там на F# правда, на C# так изящно неполучится, точнее можно — но это уже будет не так удобно, и даже настолько неудобно что плюсы начнут теряться).
https://www.youtube.com/watch?v=Up7LcbGZFuo
или это
https://youtu.be/Bn132AtZLhc