C
Size: a a a
2020 June 05
AS
AS
Там говорят что мол то что я готов напоказ туда а что прячу в internal
это скорее касается библиотек/клиентов если вы пишите
MD
А я такой хочу clean architecture сделать. И такой domain, services в internal, interface and infrastructure в pkg 🙃
Это все уже прошлый век, internal в целом уже на верхнем уровне не нужен, потому что есть modules, pkg в принципе плохой тон
C
Это все уже прошлый век, internal в целом уже на верхнем уровне не нужен, потому что есть modules, pkg в принципе плохой тон
Вот и я об этом я вначале и когда тоттгит нашел так обрадовался, а потом вижу что кто то говорит что с появлением модулей так и не нужно вот и сижу с комитом гитигнора и Мейн package
Н
Видел когда ансибл настраивал докер образ)))
Опять же зависит от специфики, но я бы выбрал докер, тк в ансибл можно написать произвольных скриптов и потом мучаться с ними. В то время, как докер это очень стандартизированное действие и особых дел там сложно натворить.
Опять же зависит от специфики, но я бы выбрал докер, тк в ансибл можно написать произвольных скриптов и потом мучаться с ними. В то время, как докер это очень стандартизированное действие и особых дел там сложно натворить.
Хочется использовать минимальный набор инструментов. Поэтому сомневаюсь нужен ли докер. В чем могут быть траблы с ансиблом?
AK
А я такой хочу clean architecture сделать. И такой domain, services в internal, interface and infrastructure в pkg 🙃
clean можно реализовать даже имея 1 пакет. Он же вообще не про пакеты, а про направленность зависимостей.
AS
Хочется использовать минимальный набор инструментов. Поэтому сомневаюсь нужен ли докер. В чем могут быть траблы с ансиблом?
развесистые скрипты на ансибле - это отдельное приложение на поддержание в актуальности которого тратятся ресурсы
с докером всё гораздо проще (если он применим в этом кейсе конечно)
с докером всё гораздо проще (если он применим в этом кейсе конечно)
C
clean можно реализовать даже имея 1 пакет. Он же вообще не про пакеты, а про направленность зависимостей.
Он то да, про направления зависимостей, но его то нужно куда то разместить и как я понял можно сделать два пакета cmd и internal в 1 положить просто мейн как spring condif который соберет default зависимости а во 2 все мои lier (domain, service, interfaces amd infrastructre) а на pkg забить вообще
AK
Он то да, про направления зависимостей, но его то нужно куда то разместить и как я понял можно сделать два пакета cmd и internal в 1 положить просто мейн как spring condif который соберет default зависимости а во 2 все мои lier (domain, service, interfaces amd infrastructre) а на pkg забить вообще
Я бы сказал, можно как угодно делать, если вы понимаете что делаете и соблюдаете правило зависимостей.
А собирают все в любом случае в main так или иначе Что руками, что с DI фреймворком.
А собирают все в любом случае в main так или иначе Что руками, что с DI фреймворком.
ЛА
Хочется использовать минимальный набор инструментов. Поэтому сомневаюсь нужен ли докер. В чем могут быть траблы с ансиблом?
Я видел, когда ансибл скрипты переписывали чаще, чем само приложение, также были ограничения и сложности с ними, ТК были общие корпоративные роли и их менять надо было коллегиально и это было очень сложно. В то время как докерфайл сам разработчик пишет.
Зависит от специфики очень. Если у вас нет проблем с ансиблом, юзайте его.
Зависит от специфики очень. Если у вас нет проблем с ансиблом, юзайте его.
SA
lib/config
/config.go
main.go
main.go
Сама задача, понять из какого именно main импортирован lib/config, и относительно етого меняется поведение inti()
/config.go
package configprogramA/
func init() {
}
main.go
package configprogramB/
import "lib/config"
const MY = "A"
main.go
package configКак в lib/config/config.go прочитать константу MY?
import "lib/config"
const MY = "B"
Сама задача, понять из какого именно main импортирован lib/config, и относительно етого меняется поведение inti()
C
lib/config
/config.go
main.go
main.go
Сама задача, понять из какого именно main импортирован lib/config, и относительно етого меняется поведение inti()
/config.go
package configprogramA/
func init() {
}
main.go
package configprogramB/
import "lib/config"
const MY = "A"
main.go
package configКак в lib/config/config.go прочитать константу MY?
import "lib/config"
const MY = "B"
Сама задача, понять из какого именно main импортирован lib/config, и относительно етого меняется поведение inti()
лучше явно передавать значение из main-а в конфиг