Hey, i’m originally from Java’s world so i need a little help about how to think in go.
Should i implement the 3 tiers architecture (PL->BLL -> DAL) with go ?
Does it idiomatic to work like that with go ?
You can look some frameworks:
A little explanation will be great.
Would you be so kind to elaborate what does PL, BLL, DAL mean?
In software engineering, multitier architecture (often referred to as n-tier architecture) or multilayered architecture is a client–server architecture in which presentation, application processing, and data management functions are physically separated. The most widespread use of multitier architecture is the three-tier architecture.
The main idea is to separate your application to 3 layers (tiers) i’ll describe the flow of a request to the server from the client, the purpose of the request is to add user to my database:
1) User has clicked on ADD button.
2) Client side send a POST request to the server with username and password on the body of the request as JSON format to www.example.com/users
3) Routing package getting the path (/users) and the request method (POST) and navigate it to the PL (presentation layer) function.
4) PL function getting the data from the request (username and password) and convert it to some struct and calling to the BLL (business login layer) function with the struct as a parameter.
5) BLL function gets the user struct and makes some validations (or any logic on the data) (e.g does user already exists ? does password length is more than 4 digits ? and so on…), if all the validation are valid, BLL calls to DAL (data access layer) function with the struct as a parameter.
6) DAL function insert the user to the database, DAL is the only layer that can aceess the database.
You should use this architecture because you have layer to every step you do with your data.
There is more reasons to use this architecture, you can read about it 
Does it idiomatic to work like that with go ?
Yes and no. Go is a different language so when you are transferring a design pattern from Java you need to adjust it to play in the context of Go.
So yes, we do use that pattern a lot in Go. No, we do not use it the in same way as in Java, especially not so strictly. In fact we do not even call it by any name. In Go it is not a pattern. It’s just writing (good) code.
Is it idiomatic? Possibly. But does it matter? The way I see it, loosely coupled and testable code is good code.
I can recommend the following articles for a more concrete example:
Also, I’ve written a detailed response in the Go subreddit on a similar case. You might find some good insights and other resources there.
2 Likes
Thanks for the clarification!
I’d check go-kit (github.com/go-kit/kit), it has a very nice separation of logic: an Endpoint holds the business logic, but for every transport (http, grpc, json-rpc…), there is a Request Decoder and a Response Encoder which translates from-to HTTP, JSON, …
The decoder decodes into a struct, which is then passed to the Endoint;
The result from Endpoint is passed to the encoder, which encodes the result fo JSON.
And of course you can layer and chain middlewares anywhere: authentication, checking, logging, measurements…
1 Like
what do you want can be (easily? 
) done in this way:
- frontend 1),2) (HTML,CSS,JS,JSON,AJAX + some Angular/JQuery/Bootstrap)
- backend Go 4),Gorilla mux 3),some Sql/Nosql driver 6)
UI can be run in Chrome app mode (with some proper CSS also works on mobile devices). you can also use REST API at backend level
.
the main disadvantage is that you must work with many languages and libraries/frameworks but your applications will be more flexible and more portable 
1 Like
Thank you!
I think i’ll use go-kit because it covers all the things i need except business logic.
What do you think about go-kit ?
Thank you!
I think i’ll use it.
It sounds great.
Do you use it ?
Yes, I do use it.
Mostly just its log package, but in two programs, Endpoints, too.
At first it seems a lot of boilerplate to have a Decoder, Endpoint and Encoder for a simple HTTP service, but it forces you to separate the parameter extraction (Decoder), real work (Endpoint) and marshaling (Encoder).
And helps you to create reusable, testable(!) components.
For example it is waaay easier to test the business logic when you have it as an Endpoint, with clearly defined input and output structs, and don’t have to create a http.Request and parse the http.Response.
So I like it.
you could try go-ddd, I went down the same route coming from .net
also it’s go-kit based
Thank you!
Thank you, i already saw this repository and i’m going try it. 
I think you’ve already gotten some good advice. I’d just like to add, as the author of goddd, that the repo was made to answer these kind of answers so I’d love to hear whether you found it helpful. Also, any thoughts on how to improve it, be it implementation details or better documentation would be greatly appreciated!
Yes, i’ve gotten really good advice here.
Implementation is great also the comments above code sections.
It will be great if documentation will be more detailed
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.