How Do You Structure Your Go Apps?

so how do you structure your go ups who here has had this question at least once in their life not surprised right not surprised I think everybody who starts out with go and even after you've been going doing go for a while it's a very common question it's probably one of the first questions that you ask probably some of these questions popped to your mind so when I started out I was like okay do I put everything just in the main package do I start out with one package and then break out in two packages over time and just kind of trust the organic growth of my app how do you decide when something should be in its own package should you just use a framework and let that take care of that what's the actual sort of idiomatic go recommendation for structure is there such a thing should you go towards micro services should you start with the monolith when you know how do you decide how much do you share between packages should your packages be completely independent even if it means some copy and paste or is you know is there a sensible way of sharing some things and splitting them up and I think that's that's those are some very common questions for you and experienced developers alike application structure is not mentioned or discussed that often there are some resources online but it's not really something that you can find a lot on online um everyone seems to have a slightly different answer to this everyone seems to have their own preferences which is completely fine but there doesn't seem to be like a unanimous this is how you do go and this is how you structure of things and go and go as a language there's already give you many hints I mean it doesn't really steer you in any particular way which is great because you can just experiment and do whatever you want but at the same time it's not very intuitive it might be hard for beginner programmers especially it might be a slightly higher level of a sort of barrier to enter entry so like I said these are all the questions that I had myself as well this is me in Iceland a month ago that like mark mentioned I've been a software developer for about seven years now so not a huge amount of experience and I've been doing go for about two years full time so I wouldn't say I'm an expert I don't consider myself an expert yet but I've written some production apps already and so I started out with PHP and then Java and then I moved to go and I'm still fairly unsure about some things and go but I think over time I've kind of worked out some ideas for how you could structure your app or what are what are the best practices that seem to be out there in the industry so this is where the idea from before this talk came came about it was like a very personal struggle that I had why should we care about structure you might be thinking like yeah sure but like stress is this really important like end of the day if it works it works right well Dave Chinese say it said probably on this stage because it was a keynote back in 2016 and at Galang UK if go is going to be a language that companies invest in for the long term the maintenance of go programs the ease of which with which they can change will be a key factor in their decision to go with go unavoidable pun so I was like yeah totally like that makes sense like maintainability of your project is a very big factor when you're deciding about a language and if you don't have a good structure for your projects then you just find yourself with inevitably with mess over time and it'll be very frustrating and I think we've all been there regardless of which programming languages I think we've all had come across projects which just didn't really have a structure and they just felt very messy and you didn't even know how to go about fixing it so let's define what a good structure actually is I think it should first and foremost be consistent across the entire project I think and it really frustrates me when there are several different styles in the same app and as a newcomer to the application not necessarily a newbie programmer but just and after you've never seen before and you're not sure which ones which style you should follow because you see like oh this part is done this way and this part is done this way so like which which style should you stick to I think your structure should be easy to navigate easy to understand and easy to reason about so it basically should just make sense by looking at the code it should make sense to you I think it should be easy to change fairly loosely coupled I think if you just wanted to make a small addition here a small tweak here you shouldn't really need to change the entire up suddenly it should be as simple as possible but no simpler and I really like this quote I think so this is attributed to Einstein there's some debate around it I think this reflects the go way of doing things that you might to go perfectly so keep it sort of as simple as you can but not simplistic the design of your app should reflect exactly how the app works because ultimately your code is the most up-to-date documentation of your software you'll ever have so if the design reflects exactly how the software works there is no wandering about oh but like the docs say that it does this but it doesn't seem to be doing this so I think a good structure basically is the best version of the documentation for yourself toward that you can have and then conversely the structure of your code should be what you set out to do in the first place so like if you start out with a certain design that structure should ideally achieve what you set out to do so I said there will be some beer in this there might not be actual beer but it will be some beer in this talk I like doing talks where I sort of talk about some real-life examples or fairly realistic examples I don't like doing talks where I just talk about foods and bars because that's not what real life is and we all know how to structure is simple here is a food class here is a bar class here is that how they can make how they made ins right but how do you go about reasoning about slightly bigger projects so imagine I gave you this spec to implement so let's say we want to implement a be reviewing service service so I the user to be able to add a beer add a review for a beer I would like the users to be able to list all the beers I'd like them to be able to list every all reviews for a given beer and just for the funsies let's say we want to have two options for storage Jason files or in memory and obviously you could add as many as you want and I also want the ability to add some sample data so just to populate the whichever storage I pick with some sample beers and some sample reviews so for somebody simplicity like I said we'll skip deletes updates skip some tests and skip some error handling so obviously this is just a demo up so let's have a look at a few different ways in which we could go about implementing this and this is where my magical switching hopefully will happen whoops I've gone the wrong way with the mouse I think there we go so it's a slightly blurry but I will open these and then zoom in can you guys all see this or should I work on zooming this in anyway it doesn't really matter what's on this screen that much I will zoom in for the important bits so I have my main function which basically does is calls populate beers and populate reviews so populate the sample data and I just creates the Rueter defines the roots and the files that we have here is data go for the sample data and we've got a model go which defines the review struct and the beer struct fairly intuitive and we've got a storage go which defines the storage interface because we you know probably some of you already jumped to the conclusion that because we have different types of storage we should probably abstract that and have an interface for it and then the the actual implementation so we've got a storage Jason and storage memory for the to implementation that is all sitting under one root directory flat it's all in the main package so that's the most obvious way to start with something like this and the August Pro is that it's easy to navigate for a small app like this I see no problem with just doing it in flat files it's the best way to avoid the risk of running in circular circular dependencies because it's all in the main package so you'll never run into that problem which is good I think it's a good starting point when you're not sure what structure you should not adopt maybe starting with flat files is just the simplest way to start and it's fairly easy to then go and like start extracting packages over time and so I think there was nothing wrong with this there's nothing wrong with Doug that keep it sweet and simple approach at least for I think it works pretty well maybe for up to like 1020 business up operations in your app I think you can still achieve it pretty nicely with flat files whoops wrong way around so this is just a summary of what was in the editor I've taken out the dependency files and all the nonsense but essentially this is this is sort of the gist of it looking at those files can you tell just by looking at the names what this app does I mean you can probably guess it maybe as a server because as it handlers ago storage Jason storage mam you can probably guess that it you know has those two but it doesn't actually tell you what this app does it doesn't mention beers doesn't mention reviews so you actually have to go into the code and open the files and look through the code to find out what this app actually is about I think that flat files are great for smaller apps for bigger apps they can be hard to navigate over time especially once those files start to grow large or if you just suddenly have to start having 20 30 40 files that's the downside you also kind of it's easy to use global State in this structure and that might be slightly risky because global State is generally discouraged and that structure doesn't really prevent you or discourage you if you from using it so let's see if we can maybe break this up or like somehow group those those things together grouping by function what do I mean by that this is something called the layered architecture and you essentially divide your code into three or however many layers you start with the sort of somewhat some of the things have to do with presentation in the user interface layer some of the things have to do with business logic like the core logic of your app some of the files are for external dependencies like databases or whatever third party things you might be talking to so if I know maybe jump to the editor just close all these things there we go so I've got essentially three directories handlers models and storage because you know some of these things are to do with the server and the endpoints and the handlers the models which is the essential sort of struts the beers and the reviews and then the storage so inside of inside each it's just few files so storage has Jason and memory models have beer review and storage so these just define the structs it's just that they're now in their own files and then the handlers just have the actual HTTP handler so get beers at beer and so on and so forth there's this film thing still I still have a file called data code that is kind of really hard to put somewhere because like where does the sample data go doesn't it's kind of like just outside of everything I mean could maybe go with the models but not quite not quite with the handlers so I've just left it in the main in the root directory and then the main just kind of ties it together so main dreamers does the same thing so calls are populating and then just creates the HTTP router so all of this might look familiar to you because all this stuff like controllers models views daos that's a classic MVC so we probably all know this from other languages or other frameworks the pros of that approach is that it's easy to decide where what goes where I mean unless you've got something like the data which is a bit ambiguous but generally if you've got a handler put it in handlers if you've got a model put it in models so it's really easy to decide especially if you're just coming into the app what should go where the Global's might start to be a bit problematic because you might now have to share some things between different packages and so you might have to start passing things in to your stripes so for example if you create like a database like instance of a structs or something and then that needs to be used by the beers and the reviews you can have to start passing that in so the global state is kind of slightly from you sir you have to start passing things more still looking at this even though you've got the it kind of gives you a slightly better idea of what the app does because even though the package names don't really tell you what the app does once you look into the the packages to see the names of the files you can kind of see be a review storage it still doesn't tell you what you can do with this app but it kind of tells you a little bit more about what what it's about there are some other things like naming talent dilemmas that start creeping in here so if you've got your models let's say you had like a user model do you call it users or user so it's the whole singular plural and do they all go in one file do you have separate ones for users and for user or like separate one for beers and a separate one for beers so you might have some start having dilemmas like this and this kind of is also hard to extend over time because once you have 10 or 20 different handlers and 20 50 however many models like those directories those layers those packages just start growing uncontrollably and you kind of get to the point where they all group completely different things together so that's a slight downside the biggest problem about this particular app though and probably quite a few of apps like this is that this won't actually compile because you've got circular dependencies in this case our beer model sorry our handlers they depend on the storage to add beers so they depend on the storage package to save the beers but then the storage package depends on the models because they saved the beers and they use the beer struct from the models the package so they use this strap here and so you've got a circular dependency between those three that storage depends on models that depends on storage because you have a storage interface which is in the models because it just defines an interface that calls some storage package memory things and then that calls the models so the beer models so you've got a dependency between the storage package and and the models package not circular dependency and if you try to compile it it would just say I can't so that's the biggest downside [Music] sorry I've gone the wrong way again oh there we go - that's one go so how about we try grouping by module so for example beers reviews and storage but like in a slightly different so take the the modules and actually name the packages after that so rather than the function it's more about like the module the group of it so I've got that in here oops so the packages are now beers database or storage forgotten every name it and reviews let's close these ones how does that look inside so we've kind of grouped the handlers and the models together because there so now everything that is about beers goes into that package and everything that is about reviews goes into that package everything is about the storage goes in here so you've got the genuine Erik struct definition as well as the implementations and then main again ties it all together pretty much doesn't really change so same thing populating and then just creating the rotors so the naming is kind of worse in this case because you've got a beer stop beer and that's the stutter that you Jen you should try and avoid and go so in this in this particular example like it's just get gets harder with the naming because now we've got reviews review and you've got storage storage or database storage so the naming isn't particularly pretty in this case and it's hard to decide as well whether it reviews really belong in their own package or do they belong in beers because it's technically reviews of the beers so you can argue both ways you could argue that it's it's its own thing or it's actually like a sub module of beers and then that is slightly it might be slightly hard to decide then like what are you you know what's a top-level package and what's like a sub package of another package you also have circular dependencies in here and I think it's the exact same on so I think database depends on the beers I think yeah so you've got the beers and reviews here and then the beer and the handler actually depends on the storage here so you've also got circular dependencies between those packages because they're all just treated equal and that has the same at the same level so this also won't compile and then you also have like some weird outer naming clashes like if you've got you've got adjacent as the storage type and then in our Jason in the actual Jason implementation I had to name adjacent storage because I couldn't name the struct and the constant for the types Jason because that would be a name clash so you get some kind of if you basically throw different things under the same module and those things might need the same name that might lead to some problems and it's still hard to know what this app does or where I should use what like if I open up the handler function and start looking at the functions I still don't quite know like if I if I just wanted to add a review I would have to look at the code to figure out you know is my add review function going to be in this package or in this package so it's not very intuitive to know like how should I use this code if I just wanted to call a function so it kind of does get rid of some problems but replaces them with RS compare to the function like functional split how about we try and group it by context so go one step further again what do I mean by context if we come back to the spec let's think about what are we dealing with here actually well we're dealing with beers we're dealing with reviews we're dealing with some storage it's probably an API because it sounds like an API and we also have this sample data to to figure out so these are the elements like our context that we're dealing with in this problem in this app it so it kind of this defines the world of this app so if you were to formalize it a little bit more you can start thinking about what everything is in this big world so as a context well we know it's an HTTP API for adding beers in terms of the language that we use to describe this app or like our terminology we can settle on beer review let's call it repository or storage or database very often you'll you'll find three or five different words used to describe the same thing in the project and then when you want to implement something new you're then wondering which one of the three or five words should I use like which which one did we settle on the entities here is the HTTP server the services that this app provides is adding a beer adding a review listing either of those things our value object so the the sort of objects that we're dealing here is beers and reviews what are the possible events that we might have happening in this app well we might get like a beer added successfully or review at it successfully we can have a beer already exist if we're trying to add a duplicate beer not found if we're trying to list something that isn't there in terms of storage or repositories well we know we need to store the beers somewhere in the reviews somewhere and then in terms of sort of things that will let us manipulate this data those value objects we need something to handle the beer aspect of things so like a beer ad er a beer list ER review either a review Lister so we kind of need those those entities as well so for those of you who already are familiar with it might have been getting some hints and also I thought that for it's very nice that you came here instead of Sean stalk but for those of you who are feel like you're missing out on the Corgi gifts I found this one last night so I figured I'll stick it in here as the drum roll because what I just what I just spoke about is something called dee dee dee what is dee dee dee domain driven development somebody told me about it randomly about a year ago and then they told me about this book this book is a brick like this fake and it's very academic and it's very very formal but it's actually a pretty like I I thought it was a very intriguing idea for how you might start thinking about your apps so this is a classic book by Vaughn Vernon I encourage you to read it to kind of get a full understanding but I'll try and I'll try and explain it in a slightly shorter and less academic academic way so what is it about it's about establishing your domain and the logic first so before you write a single single line of code you just think about what are you dealing with so what DDD is about is about defining what they call a bounded context and establishing the building blocks of your system so it's something a value object is something a repository what are what are the things that we're dealing with and you define a bounded bounded bounded context which is basically a limit of a particular model so like if like your beers might be one context and then the review might be another context and that kind of defines what has to be consistent within one context and what can just work independently and then you also define this thing called ubiquitous language which is essentially your terminology that you so you use set out and you set on the particular terminology to use across your project and then ddd kind of distinguishes between the entities the value objects the main events aggregates all those things that I just mentioned that's like formalized in the DDD model so actually Before we jump into this let me just quickly show you an example way that you could go about implementing that this is obviously just my take on this and the fun thing about DDD is that every one of us might have a slightly different idea for how to go about implementing this so this is just what I wore what makes sense to me and how I would do it but this is by no means just one way so I've I thought about this app this way well we're gonna have an adding package and then the review of reviewing package and it's essentially so DDD promotes this this idea that you named your packages after the functionality that they provide and not after what they contain so the functionality provided here is adding listing reviewing but it doesn't so the names aren't after what that package contains and I do have a package called beers and reviews just to define the structs and then the main again ties everything together it looks pretty much the same it's just like a slightly different way of initializing things but you still add the sample data still the finer HTTP roots it's just that in your packages for example in the adding package I have the endpoints and now this is like separated so this is just the HTTP layer and then they also have the service the actual business logic so the add beer and add sample beers function so it's kind of slightly more grouped so this will be just the HTTP layer this is the actual logic and then storage is the actual implementation so I just have the type for defining the type but then this is the actual bit to deal with actual saving of things so this is kind of if you do your code in this way it's like easier to avoid circular dependencies because then you the flow is slightly more clear it's it's slightly clearer because it starts at the main and then you kind of the adding the reviewing the listing will depend on the storage but then the storage won't want so much depend on this so it's slightly easier to avoid circular dependencies when you start thinking about your apps this way because you didn't start to think about the flow of control and information and I'll come back to that in a minute so like I said this is just my take on it a few slight problems with it if I wanted to suddenly add a different way of interacting with this app so rather than an HTTP API I would like to be like I'd like to for this to be a command line up that will just prompt me for beers where do I then put that new client or maybe it's just like a completely new completely separate clients that interacts with my application so where where would I put that in this project and then the sampling sample data is still fairly ambiguous it's now thrown into so like the sample beers are the final defined here and then in the actuals adding service you can adds beer or add a sample beer but it kind of doesn't feel quite right because then you're just mixing the sample beers with the actual business logic so there is something that can take us one step further from here and help us a little bit with that with that dilemma particularly about how you interact with your app and this is something called the hexagonal architecture model this is this was invented like invented popularized by alistair cockburn and it's pretty popular these days so what is this hexagon all about it has the core domain in the center so the core domain is in here and then it kind of starts to have layers that go outside so you've got your application layer of framework layers and then at the very edges it's all the third parties that you might be dealing with the input inputs and the outputs so you're gonna have your databases maybe some third party services for it party parties API all of they all of the outside world then so the main application logic is here in the center and like the goal of this model is basically the goal of approaching in the design this way is so that changes in one area of the app effect as little of the rest of the app as possible so changes to your ideally changes to the core domain should only affect the core domain they shouldn't change how you your storage works and equally if you just want to swap out the storage like if you want to swap out a my sequel database for a new sequel database or something like that you shouldn't necessarily touch your domain logic your domain logic shouldn't really care how and where you save your data like it should have that abstracted so the hexer architecture is all like I said before like it treats the inputs and outputs as the external dependencies it doesn't have like this this sort of cement it's basically completely a symmetric as opposed to the layered model which kind of very clearly defines like the inputs and then the the business logic and any outputs like view so this one just treats it all as kind of the same thing and then the key thing about the hexagonal motor is that dependencies are only allowed to point inwards and that is a very key thing about this so the idea is that nothing from the core domain should depend on anything outside of it but the things outside of it can by all means use the things defined in the core domain and that going to make sense from a lot from like the way you would think about your apps so it kind of makes sense to group the the actual called CoreLogic together and then just leave all the everything else that can be swapped in and out all the adapters all the parts that's why it's kind of called the ports and adapters sometimes it makes sense to just leave it outside and so the hex model achieves this by making a very heavy use of interfaces so you pretty much define define interfaces at every single boundary between the layers so the core domain is going to abstract everything it doesn't need to know about as interface and it will kind of just go outwards so interfaces are very heavily used in this model and if I there we go so to give you an example of how you might go about implementing that it's actually very similar to the domain driven model except for I now put two top-level packages so there is a package called command and a package called package PKG and that's something that you might have noticed in some of the projects are out there online so the command package kind of defines the entry level into your app so you've got so i've got my data sub package and my server sub package now i have two main functions and one of them is for the actual server so it just defines the endpoints as it did before but now the adding of sample data is a completely separate command so it's completely independent from the server which kind of makes sense because that's how you would think about this up to start with so now my mind doesn't always add sample data when i run it i only add sample data when i decide to run this main file and if i wanted to add a third party client to call my app or a command line interface like entry into my app I can just add another sub package under my command package that just starts that or like lets me interact with my application in a different way so it's very easy to add new inputs to this and then the package package contains the actual core logic which doesn't isn't concerned with how this app is accessed or anything it's just it has the same functionality so adding listing reviewing none of that changed the storage package is outside of the package of the pkg package because it isn't strictly sort of business domain it's probably debatable whether you'd put it all under the package which is sort of supposed to be your actual source code for the application or if you leave it outside I don't have a strong opinion on that I think you could argue both ways and on any out of file so like I've got a godet file in here all of that is under the routes directory so that's kind of how you could group this in a hex model looking at the package names again it tells you a little bit more about what this app does so you look at just the by looking at the names you know that you can add you can list reviews so I think that is a much nicer way to sort of convey what the app actually does and what you can do with it and also looking at it you kind of know that if you wanted to add something you should probably look into the adding package so it guides you along a little bit this the hex model is probably an overkill for simple apps like this like the beer ad adding package I just kind of deliberately extended it I still think that there is nothing wrong with flat files but again just to give you an idea it's kind of over complicated a little bit so maybe thinking like okay that gets us into a pretty good stage like it's a lot a lot of a sort of slightly big mind shift maybe and as that isn't even everything I found about the design yet there is also something called the actor model and here's just like a quick Wikipedia definition it treats actors as the universal universal primitives of concurrent computation and an actor essentially can make decisions create more actors send more messages or determine how to respond to a message received actors may modify their own private States but can only affect each other through messages avoiding the needs of any locks that sounds an awful lot like concurrency patterns that you might have heard about so essentially in the actual model every object is an actor with a mailbox and a behavior and all actors communicate via messages they're all independent they can all work as synchronously that's kind of the gist of it there's also no shared state between the actors which again fits fits the concurrent concurrency model an awful lot and quite well so I thought well okay no shared state that kind of invites concurrency quite a lot and indeed the the author of ddd vince van Valen vernon and he he actually got quite involved into popularizing the actor model these days and it's only been around for about I think since 2016 so it's a fairly recent trend and he reckons that the actor model is well suited for ddd and highly scalable systems and potentially simpler to implement than a typical event-driven architecture so again event-driven architecture probably some of you got that idea already so I I don't have enough allot of time left to show you a full demo but I did a quick demo of how you could go about that for the adding of sample data so essentially what I've done is introduced some go routines into the mix and that kind of that actually is you know it feels finally like proper go programming so the idea is essentially that our be rather in the review adder there completely different actors and they are they actually shouldn't affect each other cuz they don't care about each other so there's no there's no reason why we wouldn't run them as two go routines right like go add beers go add reviews and then obviously the messages that we're going to pass into those actors are going to be the beer data in the review data so the way I've done it is thrown in the adding service now defines the payload which in the case of adding beers is just an array of beers and in the case of adding reviews it's an array of reviews so that's the payload payload that this actor might receive and then there are some events that it might output so we can just say I'm done I failed or beer already so that kind of defines the events that might be transported within and then if you go back to the main I've also thrown in some channels because we need a way to know when those go routines finished so you just pass in the channel 4 beers done and reviews done kick off the go routines and then we just wait for those channels to return and then if if we get the beers result we just print out a simple summary of like finished with status bla and if you get the reviews done then you just print out finished adding reviews so this is a very simple simple thing about it I just kind of wanted to give you an idea for how you might go about defining those actors and events and messages and going up hopefully it looks a bit familiar like Oh looks familiar to you if you've done things like worker pools or communicating with channels it's essentially like the actor model is kind of formalizing what you might have already known from go programming and I think that's why it fits go quite well as a way to think about your apps a quick word on testing I've not said it much about it so far I think the best thing is what the go authors would probably recommend which is just keep your test files next to your actual files I don't think there is a much of a reason to duplicate your package structure in the test package I think it's perfectly fine to keep the test test files next to the main files I think it's also fine to use a shared mock sub package I think that's what most people would recommend these days I personally haven't found a reason to not to so I'd say keep a shared mock space sub package a quick word on naming I touched on this before so I prefer my package names to convey what the package does then what it contains it's a it sort of helps you reason about the apps a bit more so choose the names that suggest well what can be expected inside avoid generic names like util or common because that that just ends up being the gigantic bag that you just throw stuff in and then over time it just grows and just it sort of has stuff that doesn't fit anywhere else it's just asking for trouble a little bit there is a great talk by Andrew gerund on the Damien go so I'd encourage you to go in like six through the slides it's published here and like I mentioned before and that's the idiomatic go avoid stutter so avoids ending up in a situation where you might have a beers dog beer or reviews that review so same thing is strings reader not a strings string reader just it's even hard to say frameworks you might you might have been thinking well should I just use a framework is there a framework that would just do all of this for me yes and though there are some frameworks out there like go buffalo and go kit and a bunch of others the link here at the top just list I think eight or ten go frameworks from this year so there are some frameworks out there and I think it's worth checking them out to get some ideas especially if you don't know where to get started but obviously then you have to stick to that framework structure and personally I prefer to learn and experiment with this from like first principles so just do it all myself rather than stick to a framework and then I'm kind of forced to keep to stick to a specific structure like I said if you've been doing any other languages like peach peace and rubies you'll probably recognize the MVC pattern in most frameworks the last link here is something called the go build template which is kind of like a shortcut for creating the hex model it will basically give you like a make file a docker file as top level CMD package and the package package and then leave everything else for you to fill in so I think that's actually quite a cool shortcut that you could use so to sum up putting it all together and go I am a fan of the top level directory structures so the CMD for your binaries and inputs and then package for the rest of your code keep your domain types inside the root package dependencies or the third-party things like storage should ideally be in their own packages because you can then swap them in and out mock's go in a shirt sub package all the other files like docker files your dependency management files anything else I think it's fine to just stick it in the root directory the main package should be fairly small so like the main docker function should be fairly small you should just tie everything together and then just initialize the app avoid global scope gets you into all sorts of trouble once you have multiple packages and you have to pass in a million dependencies between them avoid in it as well like the reason why I don't like in it is for example if you put like I put the adding of sample data in in it to start with and then when I was writing my test and my test would run the test would obviously run the init function every time so I would add sample data every single time so it kind of gets you into trouble very quickly because it will always run I have to say that I have to give a huge credit to those people because none of these ideas is mine originally this is what Peter Bergen and Ben Johnson have been popularizing for a while as a way to write go apps in 2018 so I highly recommend you check those links they go into way more details than like reasoning behind this Marco's Elson as well he's done a talk here at golden UK I think two years ago where he talked about porting his sample DD app from Java which is like a famous ddd example into go so this is a way more complicated app that he supported and kind of tried to illustrate DDD on that so again I highly recommend that you check out his talk and his github repo if you want to see a much more complicated example of DDD so I'm sorry I don't have a single right answer there's usually no single right answer to this I like the code be like water by Bruce Lee so be flexible your structure with your structure don't be afraid to experiment and adapt keep it as simple as possible but not simpler keep it consistent and share your ideas as well if you come across if you just discover a really good way of structuring apps or if you have a really good idea then like I did I said write blog posts about it share your idea get some feedback because I think we all need we all need that and we can all benefit from that so that is all I have if you have any questions feel free to tweet me I will publish the slides and the code online and some references as well like they're just a summary of the ones that I mentioned so thank you for listening [Applause]

Channel: Coding Tech

Views: 92,163

Keywords: golang, go, go apps, go applications, software development

Id: 1rxDzs0zgcE

Length: 43min 57sec (2637 seconds)

Published: Tue Sep 04 2018