opencv это распознование образов на видео

миксер это немного другое

Логику работы модели с БД реализуют в репозитории. Методы репозитория могут принимать на вход модели и могут возвращать модели, соответственно репозиторий знает все о устройстве моделей. Имплементация репозитория находится в слое инфраструктуры, поэтому он может оперировать моделями не нарушая направления зависимостей.

Логика работы моделей - это бизес-логика. Модель в контексте DDD (да и в контексте Clean) - это не модель данных (структуры), это модель процесса (Т.е. набор структур, методов и функций моделирующих бизнес-процесс).

В репозитории же хранятся Aggregates (которые являются только частью модели. Агрегат задает consistency boundary и содержит в себе набор Entities и Value Objects). Задача репозитория заключается в том, чтобы создать иллюзию как будто данные хранятся в памяти а не в какой то специфической БД. Соответственно в репозитории хранится только логика того, как агрегаты сохраняются, обновляются, удаляются, мапятся на таблицы и т.п.

какую литературу по DDD можешь рекомендовать? желательно на русском

SaveData(db *sql.DB, data *DataClass)
OpenDataByID(db *sql.DB, data *DataClass)
и т.д.
Словосочетание "чистая архитектура" нужно знать только лишь для того, чтобы идиоты на собеседовании услышали от вас то, что они хотят услышать. К программированию это ни какого отношения не имеет

Я бы порекомендовал "Domain Driven Design" Эванса и "Implementing DDD" Вернона. Но именно на английском. Я обе читал по одному разу на русском и по 2 раза на английском. Перевод очень плохой и вносит больше путаницы. Ну и к ним надо возвращаться переодически. Т.е. прочитал, попрактиковался, перечитал. После первого прочтения, в голове как правило каша. Еще есть ресурс на котором много информации собрано. Но тоже на английском: https://domainlanguage.com/

Ну и самое главное, надо понимать: Зачем?
Есть области в которых бизнес-требования не меняются часто или не меняются вообще. Есть области в который спецификация известна с самого начала и нужно просто ее реализовать. В таком случае DDD не нужен.

модели это сущности в процессе (entities, aggregates), процесс определяется слоем бизнес-логики (слой use cases, манипулирующий сущностями и внешними адаптерами). Есть адаптеры к внешнему миру, в качестве которых может выступать и адаптер к БД, и rest/grpc эндпоинт, например.

считает МимоПроходящий

И что? не правильно считает?

нет, не правильно

(и идиотами неустановленного размера группу лиц тоже называет зря)

это все вопрос веры :) кто во что верит. часть людей верит в анемичные модели, часть не верит. твой вариант это анемичная модель *DataClass. можно к ней прикрутить метод Save(db *sql.DB), и уже будет забег в чужой лагерь.

Ну я не утверждаю же, что это универсальная модель на все кейсы, пром. стандарт, Дао и т.п. Я сам зачастую делаю repository.SaveData(data). Пойнт в том, что когда спрашивают "как сделать" в общих чертах, без уточнения деталей, правильным ответом будут тот, который самый простой.

Установленную - тех, которые на полном срьёзе рассуждают про "чистую архитектуру" в прикладном контексте. Хотя всё сводится к банальному использованию интерфейсов вместо конкретных структур

ну вот я ни одного такого не встречал.

коллега, не лезьте, пожалуйста, в бутылку.

@zergsLaw не лезь

тут взрослые сейчас трут ))

ухожу