В го стдлиб Acter не примут, можно было бы на этом и закончить

интефейс, ИМХО, не сущность, и прежде чем создавать интерфейс состоящий из Getter’ов полей, стоит задуматься над общим дизайном и подвергнуть его критике.

Наверное, но для меня например go stdlib это не библия и не эталон. 🙂 Как в общем и Effective Go, которому я конечно же стараюсь следовать, но тем не менее.

такие интерфейсы появляются из-за того что по-другому в Go низя

выше был ast.Node как пример

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

нужно ориентироваться на реальный мир, а не на идеальную модель, которая только у себя в голове

по-хорошему это должно быть перечисление

А как тогда на уровне инфраструктурного данные доменные получать верно по вашему мнению?

да, хороший пример. Спонтанно я не могу придумать название лучше, поэтому прагматичности ради оставляем как есть. Но это не значит, что более идеоматичного подхода не существует. В том же примере выше с Audio, Video был жуткий косяк автора

Вот я не увидил вообще косяка в примере с Аудио и Видео, хоть убейте. Очень легко читается и воспринимается, не вводя в заблуждение при этом. 😕

аудио поток, который создаёт поток?)))

аудио поток должен был embedd’ить io.ReadCloser, потому-что он уже потребитель потока

А вообще - все подходы же не абсолютны и нужно идти на компромиссы постоянно :) каждый проект в зависимости от требований архитектуры имеет свой набор компромиссов :)

Аудио, который создаёт инстансы своих аудио потоков, да

ну вообще получается что Streamable стримит сам себя

type AudioStreamer interface = актор, потребитель потока, он читает, абстрактный тип
type AudioFile struct = источник, сущность, он является аудио записью, конкретный тип

Там не было абстракции аудиопоток. Там была абстракция "Аудио" и "Видео". Которая помимо предоставления потокового чтения еще и другое поведение имеет. Это уже вы переопределили абстракцию и решили что это должно называться поток. Но в примере автор достаточно четко оброзначил что этот интерфейс означает. Поэтому я не вижу там проблем. Я вижу там именно то что имел ввиду автор. И у нас бы с ним даже споров не возникло на этой почве. Он все четко описал а я могу использовать это даже не заглядывая в реализацию

А context.Context как назвать? :D

просто бывают плохие компромиссы и менее плохие