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?

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:

1. Where would you put the .proto files
2. Would the protobuf service conflict the go interface service we already use
3. How do you implement a repository interface for AddBeer without having 2 structs of storage implementing the same methods.

• gRPC: func (s *StorageA) AddBeer(ctx, *pb.BeerRequest)
• HTTP: func (s *StorageB) AddBeer(beer struct goes here)

Thanks 🎉

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 :)

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,

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?

1. In domain services logic injecting a permission manager as done for repositories ?
   PROS: logic will be the same across all transports (REST, CLI, etc)
   CONS: I feel like it might not really be the proper place to put it (but maybe it is right to check permissions logic in the domain directly (e.q user, blog, post, comments))
2. In the transport handlers
   PROS: do not pollute domain logic
   CONS: logic should be rewritten for every transport method (REST, CLI, etc)

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 :)

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.

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?

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?

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:

1. Return another non-domain object from the repository (hard for slices of Beers for example)
2. Put the Beer struct in another package
3. Put the mock inside the package and not in its own folder.

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

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 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!

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.

How to manage testing in hexagonal architecture? As every package will have it's own testing file too.

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.

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:

• clone https://gitlab.com/theobouwman98/wp/tree/hex-impl
• run go run cmd/register-server/main.go

What would be a good fix for this.

Thanks in advance.

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 ?