Daniil Vasilyev

Нет никакой причины, почему нельзя было бы использовать Django для сайта клиники

Да.

SELECT * FROM base WHERE domain LIKE '%habr%' LIMIT 10000;

проще всего так, наверно:

CREATE EXTENSION pg_trgm;

CREATE INDEX trgm_domain_base_idx ON base USING GIST (domain gist_trgm_ops);

EXPLAIN ANALYZE SELECT * FROM base WHERE domain LIKE '%habr%' LIMIT 10000;

https://www.postgresql.org/docs/current/pgtrgm.html

Запрос

SELECT * FROM base WHERE domain LIKE '%habr%' LIMIT 10000;

Какой это нахрен поиск "по совпадениям"??? Это, блин, поиск по подстроке!!! причём в любом месте строки.

С таким шаблоном поиска можете с обычными индексами вообще не трахаться, по причине абсолютной бессмысленности действа. Читайте про GIN, GiST, RUM и прочие виды индексов и поиск с их использованием.

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

Соображение второе, практическое. Раз, как вы пишете "Domain содержит только сущности, Enum'ы", то выбросьте из головы слово Domain, оно вас только запутывает. Потому что намекает на DDD, а то, что у вас есть, в DDD обзывают "анемичной моделью", и сильно не любят. Т.е. сейчас, с нынешней структурой приложения, DDD - оно не про вас.

Так что, по факту, у вас есть два слоя абстракций, описывающих функции классов и методов: UI и Application. И я подозреваю, что логика приложения - классы и методы, отнесенные к Application - использует в качестве средства доступа к БД EF напрямую. То есть - что там прямо в коде используются сущности под названием DbContext и DbSet.

А это означает, если по жизни, что от EF вы в таком раскладе никуда впоследствии не денетесь. Хорошо это или плохо - решать вам. Однако о намерении прибить гвоздями свое приложение к EF вы не упоминали и, предполагаю, не думали. Если это так, то задумайтесь именно об этом. Не о замене БД - EF может работать поверх разных БД, так что к MS SQL вы, по факту, с EF привязаны не будете (ну, разве что, сами того очень захотите).

А задуматься надо: EF - штука неоднозначная. Она, подобно любому средству ORM, полна абстракций, которые, так скажем, не совсем хорошо ложатся на логическую структуру реляционных БД, а потому в них есть заметные дыры, через которые эта структура будет проглядывать. В частности, это нередко касается вопросов производительности.

Но если вы выберети жизнь EF и ни с чем другим, то о Repository и UoW можете больше не думать: EF будет для вас и тем, и другим.

Кароче, выбирайте.

Rust currently provides only the bare essentials for writing async code. Importantly, executors, tasks, reactors, combinators, and low-level I/O futures and traits are not yet provided in the standard library. In the meantime, community-provided async ecosystems fill in these gaps.

There is no asynchronous runtime in the standard library

Из документации.

Тут есть два варианта, либо оно всё же присваивается, просто вы его не можете использовать так, как нужно, либо у вас условие if равно false. Больше вариантов не может быть

UPD:
Судя по логам, у вас выводится число 10, значит внутрь блока if программа заходит, значит всё должно работать. Вы лучше не 10 выводите в Debug.Log, а значение переменной textret

заново собираю контейнер, пакую в tar.gz и заливаю на Линуксовую машину.

Может, есть уже готовые решения?

gitlab ci/cd + gitlab container registry

простой путь поставить счетчик от гугла.
Другой вариант вставить скрипт который вычитывает все что можно из клиента формирует адрес, добавляет случайное згачение и запрашивает ваш сервер

Извините, но это - "школьная" программа. Тут не решают за других "домашку". Тут помогают понять то что не понятно.

Покажите что вы делали и что у вас не получилось, и мы вам поможем понять почему не получилось.

Это зависит от слишком большого количества факторов чтобы давать однозначный ответ. Опишите ваш случай подробнее.