katzien / go-structure-examples Goto Github PK
View Code? Open in Web Editor NEWExamples for my talk on structuring go apps
License: MIT License
Examples for my talk on structuring go apps
License: MIT License
Hi!
I am referring to the hexagonal architecture example. It's a well-known idiom in Go that a consumer defines the interfaces it needs. In this particular case, why not define the three service interfaces in the http package?
Thanks!
Hi Kat, after watching your talk, I found your project structure is very inspiring and I'm migrating my project to this structure now. I have a question. Why do you want to create a Service
interface in every service package instead a Service
struct? and all functions with (s *Service)
automatically bind to the struct. Is there any special use case for Service
interface?
Hi!
I found this repository from duckduckgo. Can you add a readme with the link to the talk? I'd make a pull request but I don't feel too comfortable writing something on behalf of you
I managed to find a link to it on youtube
https://www.youtube.com/watch?v=oL6JBUk6tj0
Thanks,
How to manage testing in hexagonal architecture? As every package will have it's own testing file too.
Hi katzien,
First of all: Great talk!
But it left me with a lot of questions: I'm unsure how you would go about defining contexts. Let's say for example you have an app where you can create accounts, add contacts and share documents between them.
In your example you have an adding context, would I put the "adding" of new accounts, contacts and documents inside a common "adding" context (Which would be grouping by functionality again) or would I go and create a "register", a "addcontact" and a "createdocument" context? And if so, would I create a different context for updating e.g. the accounts and documents? If that would be the case wouldn't that mean that I would have to duplicate a lot of the validation logic?
I'm really unsure how to figure out what contexts there are in an application and how to figure out which stuff belongs in which.
Regards
BitPhinix
Since we are returning domain objects (Beer) from a repository our repository is dependent on the domain package.
However, if you try and mock it with gomock it causes a cyclical dependency Because the mock imports from package and then the package improrts the mock so do I:
What structure is proffered in case when some service needs to expose it's API calls to remote one (gRPC or HTTP) ?
Case 1)
client/grpc/client.go (returns listing.X and accepts adding.X)
Case 2)
client/grpc/client.go
types.go (defines it's own types such as: GetX and AddX)
Maybe there is better option which is not mention?
Will be grateful if I get feedback on this topic.
Dependabot Preview will be shut down on August 3rd, 2021.
It appears that this repository has configured updates for dep
.
The GitHub-native version of Dependabot does not support dep
, which was deprecated as of 2020.
Guidance from the dep
maintainers is to upgrade to go mod, which Dependabot supports.
In order to keep getting updates for your Go dependencies, you'll need to migrate to go mod
and add a Dependabot configuration for it to this repository.
Hi! Just found your talk and really appreciate it!
Thinking about how to handle an update use case using the domain-hex approach.
Based on the beer sample, let's say an update can update a beer ShortDesc
only if the beer was added in the last month (so the field Created
is needed). How do you approach it?
The Created
field can not be added in the updating.Beer
model and comes directly from the database so I'm pretty confused right now.
Thanks :)
Hello @katzien !
First of all, thanks a lot for this amazing repo showing all great examples :)
I was wondering, in a clean design, where would you put the object based permission logic?
Also, I would like to permissions information into the models so API clients knows what's possible or not to do on this model for the given user. For example, user 123
GET post 456
getting the following JSON response:
{
"id": 456,
"title": "Example",
"content": "blablabla",
"permissions": {
"userId": 123,
"canView": true,
"canEdit": true
}
}
This way, we don't need to do any extra call asking whatever the user can do X or Y on the given object like GET /permissions/posts/456
with user 123
which would return:
{
"userId": 123,
"canView": true,
"canEdit": true
}
Feels like option 1 (put logic in domain service) is better but it just doesn't sound right to have to handle this extra permission
model for each object ...
Did you have to tackle such things in the past? If so how did you do? What do you think about the above?
Thanks a lot :)
If you have a large domain with a lots of services using the storage, each defining it's own repository interface, then putting those implementations in a single folder under storage/
I find this pattern gets out of hand really quickly, it's fine for smaller examples like the beer review in this repo, but for large APIs where the storage needs to implement a couple of dozen or hundred repository functions is not really usable.
How would you organise the storage folder to break it down more?
I thought of moving the repository implementations in the domain logic, but that would circumvent this architectural pattern; and by further breaking down everything into sub-folders inside storage/ would circumvent Go's package layout.
The only, somewhat, manageable pattern I found is to create files under storage/ by the entities it represents, like storage/job.go, storage/ticket.go, storage/beer.go and write the repository implementations in these files.
Any other ideas?
First off, this is a great repo which I use often as a reference.
I adopted the DDD option in a few services with only REST APIs and would like to add gRPC support but:
.proto
filesAddBeer
without having 2 structs of storage implementing the same methods.func (s *StorageA) AddBeer(ctx, *pb.BeerRequest)
func (s *StorageB) AddBeer(beer struct goes here)
Thanks ๐
This repository gave me lot's of inspiration for my own projects but I do have one question regarding filepath.
Let's say you have a static file ( html file or other) in your "rest" package, how would you link to this file from your handler.go file ?
Hello,
I am trying to implement this structure for a new project.
What I first tried was creating a listing
and register
service for users.
But I am getting to the point where I want to GetAUserByEmail
in order to check if a user is already registered with that email.
So should I use the listing
.GetUserByEmail
in the register
service or definitely not?
Like here:
https://gitlab.com/theobouwman98/wp/tree/hex-impl
go run cmd/register-server/main.go
What would be a good fix for this.
Thanks in advance.
Hi Kat,
I watched your talking at Youtube and I have a question about entity definition in domain-hex mode.
I saw the adding/listing folder has almost the same beer definition. I know the beer maybe different between assistants and customers, but will it need to be translated between the different beers?
It's me or this is bussiness logic and cannot be here.
https://github.com/katzien/go-structure-examples/blob/master/domain-hex-actor/pkg/storage/json/repository.go#L53-L59
To my own understand bussiness logic must be inside of "Domain" layer. This a mess or a missing something?
The 'storage' package imports both 'beers' and 'reviews' packages.
The handler.go file in the 'beers' and 'reviews' packages imports the 'storage' package.
I see that it's stated that all other examples will compile, but then I see no point in presenting a 'modular' example that will not work.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.