Golang Microservices: Project Layout and Domain Driven Design

hello my name is mario welcome to another video in today's episode i will be sharing with you another tip for building microservices inco specifically the project layout that i like to use and just a quick introduction to domain driven design what is the agenda that we're going to be covering it consists of three items and like i said a quick introduction to domain driven design uh a few approaches that i have found for creating your own project layout and the project layouts are like using for building microservices in go specifically web micro services in go so what is domain driven design well this is something that was introduced officially by eric evans back in 2003 and martin fowler likes to define it as an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain what this means in practice is that there is some direct communication between the domain experts and the technical people that are supposed to be building the software that is going to be modeling whatever domain the experts are in basically think of them in terms of for example if we are building a finance system well we need people that have finance experience if you are building something medical medical related or pharma we need to have perhaps doctors doctors nurses and people that know the domain the whole point of this is that with having this direct communication between the domain the domain experts and the technical people it allows it allows us the technical people to build something that maps consistently to whatever domain we're trying to build with the whole idea is that if this is a complex domain that has a bunch of different rules we can follow the rules as close as possible because we are literally talking the same language which is one of the things that i want to highlight here um there is an interesting interesting concept called the ubiquitous language which is that's practically what it is defining a language that both the technical people and the domain expert can share and that way they can communicate and besides that the idea of having bounded context which is again thinking in terms of perhaps if you're going to finance there is a term that is specific to finance that we can separate and therefore we can allow that become a microservice and again this is why if you refer to some of the most recent videos talking about microservices or microservices in general bounded context is one of those terms that always comes up when discussing the comparison between ddd and microservices now to be clear domain driven design is not easy it takes some understanding in the context of go there is literally just a few resources to give that give you an idea how to do or use ddd with go and i will mention those and it really in practice it is recommended for large and complex systems if you're building a microservice that is supposed to be i don't know being used as a demo which is i would be thinking why even bother using dd and if it's something that is really simple and that doesn't have too much complexity don't even bother trying using dd the whole point of using again like i said the whole point of using the d is to somehow build a system that is sharing the same language like literally the human language between what we're defining what we're implementing what the domain domain experts need and the rules that we have to build and implement there are a bunch of things that are introduced thanks to to domain different design that i will be covering when the time comes when we're actually looking at the actual approach for for building this kind of uh software now this is not something new and and not the main different design but more more the project layouts and a few of your authors already talked about this and i think what we can see if we if we you know specifically look at what ben johnson and william william kennedy were discussing is that the whole idea of um creating in go for creating idiomatic code is that you need to try to make sure the types that leave in the package or the types that you're defining in your package leave make sense and live together as needed and bill kennedy likes to call this the design of philosophy the design philosophy and packaging and i highly highly recommend you to read this blog post there's a few few or i think two or three blog posts that cover um the different approach that he likes to take when when discussing and building packages and in the end building the services uh ben johnson uh also does a similar thing and where he's defining a few different ways to locate or or different places or packages where you should be putting your types that in the end all built together to represent the final domain or the final implementation one interesting interesting thing about janna is that she back in 2017 was discussing about naming the packages and again it goes back to to not only building the things that we're going to be using using something like ddd but also making making sure that the code is idiomatic and also the same time uh it makes sense in the context of what we're trying to describe she's describing a bunch of different uh recommendations that i think i if you have been exploring how to name packages it's most likely your race so this this blog post and and finally uh kat kadzian zion i hope i pronounced that correctly she i attended gophercon in 2018 and she gave a presentation about how did you do how to structure go ups and she covers a similar approach but is more related to to how you feel the the thing that you're building and again she doesn't explicitly mentions ddd if i recall correctly but in the end if you read all of these links or resources you will notice that most of them have the same idea and the whole point of them is to build something using packages that sort of make sense in the context of what you are building and at the same time those are idiomatic in the context of what go developers expect to see when reading code and building your code now in practice what i decided to do this time is is a build a implement a new repository on github that happens to have at the moment nothing is just an empty readme well not an empty readme an empty project with a readme and used the code module in his initialization right there that describes the structure that i'm using and it defines a few features that i will be implementing in in the future videos and i've been covering a few of them in previous episodes but i just want to make that clear that this is something like a work in progress and and when the time comes and when i cover a specific feature i will go back and discuss okay why did i do this in the first place so if you look at the demo that i have here it's literally empty folders but i just want to give you an idea of what this is what this project is supposed to be and and how everything is mapped to the actual domain and it goes back to the definition of bounded context that i will be covering in the future video in the next one when i'm specifically talking about the project that we're going to be building um the service that i'm implementing this time will be a simple to-do list app management kind of a service thing uh i was i was trying to find a good service that everybody is aware of and it's easy to understand and i didn't want to introduce something that perhaps it wasn't that clear enough for everybody and i i think that all of us have built already a to-do management app or cli or web app or whatever so we're familiar with the basic rules of managing to do items i will i will be adding the features here we go and i will be introducing the the different things for for that in the end makes sense for building a final micro service that that you can put in production in practice most of these things are the same for all the microservices i mean you can argue that most of them depending on the need require some of the things but most of them follow the same structure and the structure that i get to follow in this case is i have a build package that happens to include some information about the build binaries or the binders that we're trying to build most likely using docker and docker files if we are using some cloud provider like aws or google cloud we build a folder that defines all the infrastructure logic that we have to define here there for for having managing everything as a using infrastructure as code the cmd will be consisting of the binaries that will be available via the different either services or tax definitions or depending on the cloud provider whatever they like to call those things basically whatever the pod if you use kubernetes or something like that so the binary that is actually running and then being uh exposing the the features that your customers use db is something that we i already mentioned in a few videos ago it includes the migrations and see the data if needed and internal is something that people sometimes don't like to to see in projects but again this is specific to a micro service that happens to be a web service and it's not a package or or a tool or a go package that you are going to be including directly most of the times however if the use case is needed if we need to define a way for other go projects to import our packages or or what we're going to be defining is implementing the public api and whatever api we decide to implement we'll leave under the pkg folder again all of these are sort of conventions which i think makes sense in in the long run and i have seen i have seen them work in real life and i can recommend them i will be giving you more concrete details about this i'm not suggesting to name your package your packages sub domain one and some domain two these were sort of like examples and with the same is that i want to give you a more better explanation why this is called postgres or memcached or my sequel but i will do that in in future episodes with that being said i think um i think the important bit about this is that not only show you the idea of this uh the future episodes but how the actual layout looks like in the beginning but also the same time to give you more resources so you can look at what is available right now what some other ideas some other people have and the end just you you make your own decision and and i just want to tell you that again it depends on the project it's trade-offs and this is something that for me has it has been working for a while for again for microservices web apis for packages or some other type of projects it's a different story and i will recommend a different layout but this is what it is for specifically microservices and with that being said thank you for watching and i will talk to you in a different episode until then you know keep it up don't give up goodbye

Channel: Mario Carrion

Views: 26,798

Keywords: golang, microservices, golang microservices, golang web development, building microservices go, building microservices golang, golang rest api, golan project layout, golang ddd, golang doman driven design, golang project layout tutorial, build microservices golang, golang ddd layout, golang organize project, golang layout, golang repository structure, golang style guide, golang packages names, golang structure apps, golang standard layout, golang project structure

Id: LUvid5TJ81Y

Length: 12min 8sec (728 seconds)

Published: Wed Feb 17 2021