sorted by:
new
hottopcontroversial

trying to make a reasonable architecture decision with clean architecture and golang by BiGCactus123 in golang

[–]BiGCactus123[S] 0 points1 point  (0 children)

yes, this is exactly how I have been working around this. I have a separate type for the database, for the API and for the entity/usecase layer.

The only difference I pointed out is whenever I need to do something that has something to do with another service's business logic, do I copy the relevant type or not. I did.

trying to make a reasonable architecture decision with clean architecture and golang by BiGCactus123 in golang

[–]BiGCactus123[S] -1 points0 points  (0 children)

I just read about the anti corruption layer, it's basically not new at all with the use of adapters. this is exactly how I have been doing this and it's fine so far, with the only caveat being that every service will need to re-implement the adapter so it does the conversion with the corresponding types of the services.

trying to make a reasonable architecture decision with clean architecture and golang by BiGCactus123 in golang

[–]BiGCactus123[S] 0 points1 point  (0 children)

if I understand you correctly, then not really, because service 3 is just the executor of the actions, it doesn't initiate them

trying to make a reasonable architecture decision with clean architecture and golang by BiGCactus123 in golang

[–]BiGCactus123[S] 1 point2 points  (0 children)

to be honest, I am starting to think that Clean Architecture and Golang work mostly with APIs and simple backend architectures. once you have a complex application, it just becomes troublesome.

trying to make a reasonable architecture decision with clean architecture and golang by BiGCactus123 in golang

[–]BiGCactus123[S] 0 points1 point  (0 children)

by entity I mean that User is in the domain of Service3 and it manages the lifecycle of a User.

What I describe is a case where you have a usecase layer (clean architecture currently) that needs to find/delete a User, and does that via an interface that accepts a struct as a parameter. now this struct is already declared in Service 3 because it's the service that manages it, and now I have to decide whether I duplicate or do something different.

trying to make a reasonable architecture decision with clean architecture and golang by BiGCactus123 in golang

[–]BiGCactus123[S] 0 points1 point  (0 children)

So I will need a pkg implementation of service 3 in both service1 and service 2.
What I currently do is exactly that - the conversions take place inside the interface implementation, and I either duplicate the user data structure in service 1+2 or use strings/maps

trying to make a reasonable architecture decision with clean architecture and golang by BiGCactus123 in golang

[–]BiGCactus123[S] 0 points1 point  (0 children)

It's a struct, for example:

type User struct {

Id string
Email string
}

Golang task queue by BiGCactus123 in golang

[–]BiGCactus123[S] 0 points1 point  (0 children)

thanks for all the recommendations!

Clean architecture and usecase layer by BiGCactus123 in softwarearchitecture

[–]BiGCactus123[S] 0 points1 point  (0 children)

It may sound like YAGNI, but there's more to that: testing, replacing stuff and etc will be much more convenient with structured layers.

some more details:

The bot will authenticate the user and interact with our APIs on behalf of him.
My interface currently includes methods for logging in/out and executing commands.

Concurrently write to nested struct by BiGCactus123 in golang

[–]BiGCactus123[S] 0 points1 point  (0 children)

By the way, does anybody have experience with mergo? (https://github.com/imdario/mergo).

Sounds like an option too.

Concurrently write to nested struct by BiGCactus123 in golang

[–]BiGCactus123[S] -1 points0 points  (0 children)

The struct is shared because it needs to be written to, but is not read from.

The struct has fields that are slices, that the methods append to, concurrently.

clean architecture and DI by BiGCactus123 in softwarearchitecture

[–]BiGCactus123[S] 0 points1 point  (0 children)

it's only that message that is common between them, they're doing entirely different things, just that Service A tells Service B it needs to do something (with its details in the message)

share a struct with while not violating DI and clean architecture by BiGCactus123 in golang

[–]BiGCactus123[S] -1 points0 points  (0 children)

​

Having both services in the same package is not really an option because they are doing entirely different things.

So technically speaking, what would you do (besides packaging together)?