Roman K

Предметная область — множество всех сущностей и их отношений в рамках контекста.

Например:
В рамках магазина это покупатели, продавцы, товары, цены, скидки, поставщики, процесс продажи, прихода на склад, возврата и т.п.
В рамках дискорда это пользователи, серверы, комнаты, группы, права на доступ, процессы присоединения к серверу, входа в комнату, оплаты nitro, написания текстового сообщения и т.п.

В целом, это всё, что понимает твой менеджер и ничего, что он не понимает. В предметную область не входит, например, то, где именно ты хранишь данные — в mysql, в файлах, получаешь и сохраняешь их по API или хранишь их в redis'е. Но входит абстрактная сущность "хранилище". Она же — интерфейс репозитория. Репозиторий — это паттерн, который скрывает реализацию конкретного хранилища и который оперирует объектами доменной модели — элементами предметной области, как будто они хранятся у тебя в оперативной памяти. Например, у репозитория могут быть методы

users.getByID(1234), users.save(user), users.getByEmail("hello@world")

и т.п. Реализация репозитория определяет, куда именно сохранится этот user или откуда он скачается. В одну таблицу или в несколько. Нормализованные ли будут данные лежать в РСУБД или денормализованные. Именно здесь можно реализовать запись в master, а чтение с реплик. Или энкодинг в msgpack и передачу его по API куда-то. Или по gRPC. Потому что предметная область не должна перегружаться деталями реализации хранилищ.

Про доменную модель:
Словарь (он же хэш, он же ассоциативный массив) — это не доменная модель (хотя в некоторых функциональных языках может быть). Объект ORM — это тоже не доменная модель, хотя много где пытается ей быть. Доменная модель не зависит от конкретных фреймворков, баз данных, оптимизаций этих баз и прочих навязанных технической составляющей сущностей. Чаще всего это обычный класс на языке, на котором пишется код (или struct в случае Golang).

Недавний пример:
У сущности есть теги по категориям:

{"category1": ["foo", "bar"], "cat2": ["foo", "hello", "world"]}

. Их так удобно представлять на уровне предметной области, об этой структуре я могу общаться с заказчиком. Но в монге они сохраняются в виде

['category1%%foo', 'category1%%bar', 'cat2%%foo', 'cat2%%hello', 'cat2world']

, потому что так их легче индексировать и быстрее по ним искать. Но это скрыто в реализации репозитория, доменная область про это ничего не знает. Это даёт сразу много преимуществ:
1. Это очень просто тестировать, без всяких моков. Вместо репозитория с монгой я делаю репозиторий, который хранит сущности в оперативе. Всё, тесты бизнес-логики не зависят от инфраструктуры. А репозиторий монги я тестирую отдельно, мокая запросы в саму монгу или даже не мокая
2. Это облегчает понимание всего продукта. Мозг не пытается составить полную картину, когда запросы в БД перемешаны с логикой, тут же сплиты-джойны строк, какие-то ещё низкоуровневые действия. Мозгу легко ориентироваться в пределах уровня. На уровне репозитория я думаю о том, как сущности хранить и доставать из хранилища, на уровне служб я думаю о том, как сущности взаимодействую и какие их них нужно извлечь/сохранить, но не как
3. Рефакторинг очень простой. Даже теоретическая смена БД. Завтра с монги нужно будет перенести одну сущность на постгрес — без проблем. Я напишу один новый репозиторий, не затронув ни строчки кода за его пределами, кроме места, где он создаётся. При этом, остальные сущности могут лежать всё также в монге

Доменные модели бывают богатыми и анемичными (но не бескровными). Оба подхода применяются и, имхо, не является антипаттерном ни один из них. Лично я использую анемичные модели, а всю бизнес-логику храню в службах.

class X:
    _created = 0

    def __init__(self):
        X._created += 1

for _ in range(10):
    X()

print(X._created)

Создать новый список и добавить туда элементы, которые подходят под предикат. Типичный map/filter/reduce

def filter_by(self, data: list, param: dict) -> list:
    result = []
    for el in data:
        matches = True
        for name, val in param.items():
            if el[name] != val:
                matches = False
                break
        if matches:
            result.append(el)
    return result

Или однострочником

def filter_by(self, data: list, param: dict) -> list:
    return [el for el in data if all(el[name] == val for name, val in param.items())]

rule of dumb: если метод/функция меняет свой аргумент, она не должна его возвращать (обычно это значит, что она вообще ничего не должна возвращать), имя метода/функции при этом должно явно говорить, что аргумент меняется (populate, remove_smth, drop_smth). Если метод/функция возвращает что-то, она не должна менять аргументы.

Но нужно понимать, что сложность создания нового списка — O(n) [при условии, что param достаточно мал и не растёт с увеличением data], а сложность выкидывания элементов по индексу — O(n**2) [потому что сложность операции .pop(idx) — O(n), в цикле по data — ещё O(n), итого O(n**2)]

Есть.

1. Сложить два списка, результат отсортировать. Сложность O(n*log n)
2. «Слияние отсортированных списков». Алгоритм нагуглить, написать самому. Сложность O(n+m)

Но если списки не размером по несколько миллионов, проще и быстрее первый вариант

https://www.python.org/dev/peps/pep-0498/#s-r-and-...

import urllib.parse
s = '%D0%B7%D0%B0%D0%B3%D0%B0%D0%B4%D0%BA%D0%B8'
urllib.parse.unquote(s)

[x for x in my_list if x is not None]

1. 20мб — это вообще не бигдата. Бигдата — это 20тб
2. В JSONе в основном массиве 3к элементов — это копейки. json.load у меня отработал за доли секунды
3. Подозреваю, что основная проблема в том, что условие if ret< 54.532 and ret >56.5343: никогда не выполнится. Потому что не существует числа, которое будет меньше 54 и больше 56 одновременно

ORDER BY likes DESC LIMIT 3