Как вы решаете проблему циклических импортов?

Question

[un1t]

У меня проект структурирован по сущностям. Напрмер есть пакет product и в нем лежит все что оносится к продуктам - модели, хендлеры и т.п. Все было хорошо, пока не столкнулся с циклическими импортами.

package orders

type Order struct {
  Payments [] paymetns.Payment
}

-----------------------

package payments

type Payment struct {
  Order orders.Order
}

Как вы решаете такую проблему?
Я пока вижу вариант переделки структуры проекта - все модели в пакет models, а все хендлеры в пакет handlers. Но мне кажется это не очень удобно. Может быть есть какие-то еще варанты.
Как вообще это принято в go?

Comments

[Lynn «Кофеман»]

https://jogendra.dev/import-cycles-in-golang-and-h...

[12rbah]

Я пока вижу вариант переделки структуры проекта - все модели в пакет models

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

[midia21]

В плане организации golang кода сильно помогла эта статейка, на всякий случай оставлю это здесь: https://blog.learngoprogramming.com/code-organizat...

Answer 1

[Александр Павлюк]

orders и payments должны лежать внутри одной модели.
Если кода много, то можете вынести эти структуры в отдельный пакет, посвященный только внутренним структурам данных, это и будет та самая одна модель.
пакет structures: типы orders и payments
пакет orders: импортирует structures
пакет payments: импортирует structures

А в целом, в го связанность кода (и кольцевые импорты вместе с ней) принято разрушать через использование интерфейсов.
У вас в идеале должны быть пакеты с моделями, в которых должны лежать внутренние типы данных и объявлены интерфейсы к внешним источникам типа баз данных, итд.
Внутри пакета базы данных у вас должны импортиться структуры данных из модели и производиться конверсия сырых данных в структуры модели. А сама база данных в модели объявлена через интерфейс, поэтому пакет базы не приходится импортить.
Такая схема дает еще плюсы, что легко тестить модель, подменяя базу моками.

Answer 2

[Дмитрий]

Структуры должны лежать в одном пакете. Если надо, в разных файлах - логическое разделение.

Answer 3

[darst]

Зря думаете, что переместив модели в папку models будет что-то неудобно. Это кстати один из вариантов чистой архитектуры или DDD.
Кидайте все модели в папку models, а там уже можете из раскидывать по файлам, те же Payment и Order.

Comments

[midia21]

Может ошибаюсь, конечно, но мне кажет для go чистая архитектура и ddd (как его обычно реализовывают) инородны (что то вроде пытаться писать как на java). В той же стандартной библиотеке вы не найдете разбиения на общие папки - models, controllers, utils, helpers и т.д. - все что относится к определенной сущности лежит в пакете этой сущности, т.е. есть пакет (папка) user, а в ней - model.go, helper.go, util.go без каких либо лишних вложение (порой пакеты в go могут содержать десятки файлов без вложенных дерикторий и это вроде как норм). В доке сказано, что на стандартную библиотеку нужно опираться как на пример "идеального" golang кода.

[darst]

Правильно. Потому, что это пакеты, а не веб сервер. Поэтому нет там такого наименования.

[midia21]

darst, Да в принципе разницы особой нет между вебсервером и низкоуровневыми утилитами. Архитектурные решение независимы, я считаю, от сути задачи. Если не убедил, вот пример кода официального golang сайта - https://github.com/golang/website В данном кейсе тоже отказываются "фрэймворкоподобной" структуры в пользу разделения логики на сущности.

[midia21]

darst, Впрочем я тоже считаю, что для создания вэб-приложения больше подходит подход чистой-архитектуры и ddd. Имхо на PHP, Python, Ruby гораздо легче и качественнее решать подобные задачи (писать вэб приложухи, блоги, сайты и т.д.) чем на Go. Он по идее для других целей создавался и хорошо справляется с микросервисами, низкоуровневыми утилитами и прочими нетривиальными задачами.

[darst]

Можете отрицать и упираться, но реалии жизни диктуют своё. Сейчас многие компании (особенно крупные) переходят на DDD или чистую архитектуру. Эти практики архитектуры намного лучше для понимания другими вашего кода, соответственно его поддержка, чем то что предлагаете вы. Поэтому если пишете для себя , то можете писать как вашей душе угодно.

[midia21]

darst, Не ну да, это мое мнение. Ничего не навязываю :) Кейсы в любом случае очень разные бывают.