{
"Name": "oracle_default",
"Id": "b0319c782cb2bf18bfe5e60dc2757b0d263866e3a7a391483bda3f183b9da9e1",
"Created": "2022-04-04T16:09:11.751232562+05:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "192.168.0.0/20",
"Gateway": "192.168.0.1"
}
]
},
"Internal": false,
"Attachable": true,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {},
"Options": {},
"Labels": {
"com.docker.compose.network": "default",
"com.docker.compose.project": "oracle",
"com.docker.compose.version": "1.29.2"
}
}
/tmp/name_filecommand:
bash -c "python manage.py makemigrations
&& python manage.py migrate
&& python manage.py loaddata fixtures/initial_data.json
&& python manage.py rqworker
&& python manage.py rqscheduler
&& python manage.py runserver"
С этим:
согласен и даже добавлю - юс кейс не обязан включать в себя функционал по изменению состояния системы.
При этом - формирование отчета может проходить далеко не только на стороне БД + иметь под собой n-шагов.
Например:
Шаг 1: Забравть сырые данные, без условий выборки забрать из БД средствами SQL/NoSQL
Шаг 2: Пропустить их через сложную/хитрую обработку, которую не возможно реализовать на стороне БД (и вполне вероятно что этого не нужно делать)
Шаг 3: Конвертировать проанализированные данные в требуемый выходной формат (xlsx/json/pdf/...)
Шаг 4: Оповестить пользователя/другую систему/... что работа завершена
Для справки:
Data Lake/Warehouse идут рука-об-руку с шагами 1, 2. Но там все посложнее и имеет свою специфику:)
Еще я не понимаю, к чему эти противоречивые тейки...
Вначале ты говоришь это:
После - это:
Зачем и о чем это?..
Ага, тянуть абсолютно все поля - нормально... Я тебя понял:)
Теперь к:
Как раз таки связан.
Я описал 2 возможных варианта решения сложившейся ситуации, которые мне с ходу пришли в голову.
Также, прошу заметить, что я нигде не говорил о том, что эти 2 варианта являются production-ready решениями.
Это плохие примеры решений 'в лоб', как раз нацеленные на то чтобы дать будущему комментатору больше контекста -
что я действительно не знаю как решить эту ситуацию 'красиво'/'правильно'/production-ready и поэтому прошу помощи.
И так, принцип Open–closed principle связан с примером, где поястоянно вносятся изменения в один класс (для атрибутов задается значение по умолчанию, равное Null/None/...), из-за того что появляются новые юс-кейсы со своими потребностями.
Спасибо за предложение.
Первую книгу я почти прочитал, с паттернами для работы с бизнес-логикой я знаком.
Про DDD - Эванса намеренно не стал читать. Прочитал Вернона - Domain-Driven Design Distilled, Влада - Learning Domain-Driven Design.
Там (как и большинстве технической литературы) явного ответа как поступать в таких кейсах - нет.
Спасибо. Тоже об этом думал, но если в доменная сущность претерпит какие-то сильные/глобальные измения - эти измения небохдоимо применить во всех местах, где это потребуется.
То есть потенциально, при таком подходе - таких мест будет больше.
А уже это - потенциально может привести к ситуации где не всё привели в ожидаемый вид - то есть допустили ошибку из-за человеческого фактора.
Да и про DRY думаю стоит помнить, когда для двух разных юс-кейсов, но со схожим атрибутивным составом на процентов 60-70 будет писаться 2 разных доменных модели.