dotGo 2019 - Kat Zień - Achieving maintainability with hexagonal architecture

[@DannySchimke]

Thanks for this great talk! I am still a bit confused how to apply this to go-code. I am still searching for a best-practice/often used way, how to structure the packages for a hexagonal-architecture-driven app. Should every layer be in its own package ("domain", "app", "infrastructure") or should there only packages like "service" and we have to know to what layer it belongs? I stop now, I have many more examples for such questions :D

[@neoloaded]

The interesting outcome of adopting a Hexagonal Architecture pattern is - you can audit the effort spent on developing the actual domain layer vs all the interfaces in the application layer to talk to the external world. Even a simple audit of Git commits will show where the spread of effort is. A personal philosophical point is - modern Cloud-based app development has a highly skewed ratio towards interfacing with external services than improving the domain layer. Utilising external providers for non-core components is great, but is the Application development then just an assembly line for combining core parts produced elsewhere (borrowing an analogy from automobile manufacturing) and later slapping the brand logo on the assembled product?

[@Velobetty]

Enjoyed this talk and interesting to see these patterns applied to Go.

[@user-vz9cj1ox3m]

ToMuchTheorieException !!!

[@JanacMeena]

Great talk for a beginner like myself. Thank you.

[@alessandrob.g.4524]

Don't you have an example code?

[@andrewshatnyy]

Any way these concepts can be explained with a real life scenario? This all reminds me Russian University so much high level abstract maths but no concrete example ruins the subject for many engineers. I appreciate the idea walkthrough but it still missing the application :(

[@froop2393]

17:05 thats the key point of the talk.

[@pricesmith8450]

why would she not give examples in these talks? not throwing shade, just dont get it... at all

[@froop2393]

Then you would see that the effort is to high...

[@32BitChronicles]

very interesting talk, the only bad thing is that the constant camera changes are very distracting

[@a0um]

Onion, Hexagonal, Screaming, Ports and Adapters, …why not just “domain-centric service architecture”? Once you put the domain model at the center the rest follows naturally.

[@rodelias9378]

Awesome talk!!

[@trozzonick77]

Hexagonal was good when was taught about it, big monolithic applications. Using in in a real microservice architecture feels like a massive overhead.

[@lule642]

What so you prefer?

[@bunnihilator]

this is gold

[@alessandrob.g.4524]

You nailed it, girl!

[@notangryjustdismayed]

that glass of water right next to the laptop is making me nervous

[@yukibuwana]

ha.. ha.. ha..

[@acupfb]

Yes, don't over engineer/over optimize at the beging

[@bacharsaleh6984]

Nice talk ,but I have heard this explanation more than 5 times by different speakers. It's better to add something more valuable to the talk than repeating.

[@ErincFrtna]

I think Kat’s gophgercon presentation is much more better.

[@fingesso]

Thanks for the feedback (and I'm glad you liked that one). If you don't mind elaborating, what was better in the other one?

[@namazbekbekarysuly9112]

Are you about gophercon uk 2018. I will take a loot at it too. Thanks.

[@alessandrob.g.4524]

@@fingesso You are not Kat Zień!

[@farhadegza2]

It had a nice start with engaging the audiences but then got boring by just reading from the laptop.

[@fingesso]

Thanks for the feedback! I agree that the delivery could have been more polished, but I had very little time to prepare & it's a very short slot so I had to make sure I stick to the script. I haven't been doing public speaking for that long so the nerves still show up at events of this kind :)

[@kalekold]

These patterns are exactly what the Go team were explicitly trying to avoid!

[@ItslennyDe]

Could you elaborate on that?

[@fingesso]

As above, if you want to start a discussion, start with some constructive feedback. Do you have any links to materials backing your statement? Are you part of the Go team? Are you saying that people shouldn't be applying this design pattern to their Go code? If so, why?

[@kalekold]

@@fingesso "Clear is better than clever." - Rob Pike "You should be thinking about writing simple clear code rather than trying to make the cleverest, densest stuff you can." - Rob Pike kzbin.info/www/bejne/hnKknHaJj7p6Z8Um35s In the talk above, even she has trouble trying to explain what the hell she is on about.

[@Dolanor]

@@kalekold Hi, I must say that the hexagonal architecture has been used in a few packages inside the stdlib. The image package for example declares the image.Image interface of each concrete image implementation. And a image/png.Reader.Decode returns an image.Image. And the quote from Rob is more about "clever" one-liner that are unreadable afterwards… Or things like template meta programming. The hexagonal architecture is quite explicit and boring in the end, not so "clever".

[@namazbekbekarysuly9112]

Author of the comment certainly doesn't know anything what he is talking about. Introducing some patterns to your architecture does not necessarily mean it is going to be bad. It mostly depends on how you will implement them.

[@in9952]

Seems she doesn't even understand what it's all about.

[@fingesso]

Care to tell me what it's all about then? ;) I was asked to prepare an 18 minute talk based on a talk which I normally give in 45, so naturally it doesn't go into all the details. Granted, the delivery could have been more polished (I had very little time to prepare and the timing was strict), but I stand by the content 100%.

[@Velobetty]

She explained the topic and clearly understands it perfectly well. I look forward to your presentation.

[@methodsignature]

@fingesso imho you do seem to know the content well. Thanks and this was a good intro to Hexagonal for me. i would like to challenge the notion that the point of DI/IOC is "to keep changes local". That is true for DI, but not true for IOC. I like the explanation of IOC in Clean Architecture. It gets at the WHY we should use IOC. Uncle Bob actually sets up the interactor (application) layer as the core, most independent layer in Clean Architecture. That is where business rules live. When the core then needs to change it is b.c. of a change in business rules and other layers must fall in line. It is important that the Interactors are completely independent b.c. you don't want a change in, say, how the API adapter is defined to cause the Interactor layer to change and end up having a knock on affect to yet other things that depend on the Interactor layer. The architecture helps drives maintainability through this inversion. When something "less central" needs to change, it won't have impact on more central layers that impact a greater share of the system. The same seems to apply for Hexagonal, except that the domain is the core of that system. Also, maybe you misspoke that "if the domain needs to change, you shouldn't really need to change the outer layers" Better would be "if implementation details within the domain need to change, ...", but that is probably more of a distraction in that part of your presentation. By definition, changing the interfaces declared in the domain will require related outer layer adapters to change. - Just another aspiring systems architecture student seeking knowledge and happy to have my understandings challenged.