Golang Microservices: Repository Pattern, Dependency Injection and Services.

[@MarioCarrion]

*Blog* mariocarrion.com/ *Example code* github.com/MarioCarrion/todo-api-microservice-example/tree/54a5a405e687cd893a5e7c78ae5006c055b941e9 *Building Microservices in Go* kzbin.info/aero/PL7yAAGMOat_Fn8sAXIk0WyBfK_sT1pohu *Go Tools and Packages* kzbin.info/aero/PL7yAAGMOat_HEEOvH99agDs_5g51A0Ls3 *Testing in Go* kzbin.info/aero/PL7yAAGMOat_HSeW4zF0uRL9EaHadE4ZZq *Keep it up!*

[@Cruzylife]

Best technical Go videos! Thanks Mario

[@MarioCarrion]

Thanks. I'm glad you find the content useful.

[@jojojawjaw]

Great tutorial, thank you

[@MarioCarrion]

You are welcome Sarah, take care!

[@luissebastianmontanares4102]

very usefull explanation! thank you

[@MarioCarrion]

You are welcome! Thank for watching.

[@rouabahoussama]

Great video thank you.

[@MarioCarrion]

Thanks for watching!

[@aftalavera]

Gracias Mario

[@Peter-xn9bk]

Good content. Thank you a lot.

[@MarioCarrion]

Thanks for watching. Stay safe

[@eduard7746]

With much respect to you and your channel, I feel obligated to offer my viewpoint about the material you make and the effort you put out. 1. In the context of teaching or tutorials, using vim or any other tool with the same UI is not the ideal way to illustrate code / project structure. People want the architecture and directory structure to be in front of their eyes all of the time so that they may form a visual memory and ask themselves questions that the structure can answer. 2. Having a piece of paper where you write down all of the key concepts with well-written sentences can help you make your speech more professional and avoid using a lot of "filler words" and making mistakes, because doing so causes students to deflect and skew, making it difficult for them to form a complete idea in their heads.

[@MarioCarrion]

Eduard, thanks for your eloquent feedback. Take care.

[@pricesmith1793]

​@@MarioCarrion It's an interesting topic. And I'd imagine it's a matter of opinion/context (who the audience is/what Mario's personal style is). That being said, I'll share my opinion and respectfully and lovingly disagree :D 1) I think this is mostly solved by having the code provided, as it already is. Any "mystery" around what's being shown can pretty easily and reliably be caught up on by looking through the code, esp revolving code structure. Not that I've had to do it much here, I personally like having to supplement learning with googling, reading, autonomous action. However, I'm somewhat biased as I really don't want someone to slow down for my sake as long as the content is contextualized well, like this! 2) This is a pros/cons kinda thing too. I'd rather not have someone read to me if they're smart and self-aware enough to make sure that the right idea ultimately comes across, as Mario clearly is. Otherwise, it's a slippery slope into "over-polishing" . . . Again, justtttt my two cents

[@buacomgiadinh1]

thank you

[@GustavoDiaz93]

It would be great to see an example about the criteria pattern and the repository one, the typical examples don’t take this into account, only show the basic implementation.

[@juanmamani2110]

Mario gracias por compartir, bastante útil el video! ¿Cuándo haces uno para uno para implementar "boundery limits by subdomain"?

[@pricesmith1793]

Do you have any info on your vim setup or general vim recommendations for golang?

[@MarioCarrion]

Yes, I have a video kzbin.info/www/bejne/Z3qsnqN_Zs6Epdk and here's the configuration I currently use for neovim using LUA gist.github.com/MarioCarrion/06346c6ec6d26e10d94627d90d78733f

[@thuocnguyen4023]

how can we handle transaction on multiple repositories?

[@MarioCarrion]

I'm working on a video covering that. Cheers

[@thuocnguyen4023]

​@@MarioCarrion great!!!

[@pumparam_5904]

Hello. How do you work with transactions in ddd? Sometimes we should execute methods from some repos in one transaction. If I put transaction on application service level then how can use it with repo? How make it better? Thanks

[@MarioCarrion]

Hello DDD does not really mention anything regarding transactions but rather it focuses on a concept called Aggregate, which is backed behind the scenes by a Repository. The idea is to group everything that belongs to an Aggregate and use the same Repository to make any and all changes. In practice there are two cases: 1) the repositories meant to be used are in the same datastore or 2) the repositories meant to be used are in different datastores. (1) is really the easy one, in that case we should group all of those repository calls and consolidate them into one to work as single transaction, for (2) there are different ways to handle it, but it basically involves calling those stores and in cases when things fail invoke calls to compensate the failed call. I hope that helps.

[@pumparam_5904]

@@MarioCarrion Thank you for answer! I read about saga pattern and unit of work. I think it can help me too. Big thanks!

[@pedroluzio]

Great video, thanks. Quick question: What do you think about using DTO's instead of passing all those argunments in the methods? you could just have (context, dto)

[@MarioCarrion]

Hello Pedro, yes, I made a note somewhere in the repo about doing that; there's a tradeoff though, we may need to enforce using all fields (or almost all of them) via a linter, I will cover that change in future episodes.

[@pedroluzio]

@@MarioCarrion Hi, thanks for the reply. One thing I like about DTO's is that you can easily add validation to it, like `validate:"required"` to the DTO struct instead of doing if name == "" { return errors.New("name is mandatory") }, you can also add methods to the dto.. for example having the Validate in the dto has a method. My problem with this approach is that is that the package where the struct is needs to cross layers (when using the Domain Driven Design). Do you have any idea where you would put the DTO's in this case?

[@MarioCarrion]

Yes, using Args/Params-like types for things like this has the tradeoff you mentioned, if the decision is to use types like that I lean towards defining either those in the domain package ("internal" in our example) or creating a new package "internal/args" that may import "internal" in some cases; both options have their tradeoffs.