*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!*
@Cruzylife10 ай бұрын
Best technical Go videos! Thanks Mario
@MarioCarrion10 ай бұрын
Thanks. I'm glad you find the content useful.
@jojojawjaw2 жыл бұрын
Great tutorial, thank you
@MarioCarrion2 жыл бұрын
You are welcome Sarah, take care!
@luissebastianmontanares41023 жыл бұрын
very usefull explanation! thank you
@MarioCarrion3 жыл бұрын
You are welcome! Thank for watching.
@rouabahoussama3 жыл бұрын
Great video thank you.
@MarioCarrion3 жыл бұрын
Thanks for watching!
@aftalavera7 ай бұрын
Gracias Mario
@Peter-xn9bk2 жыл бұрын
Good content. Thank you a lot.
@MarioCarrion2 жыл бұрын
Thanks for watching. Stay safe
@eduard77462 жыл бұрын
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.
@MarioCarrion2 жыл бұрын
Eduard, thanks for your eloquent feedback. Take care.
@pricesmith17932 жыл бұрын
@@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
@buacomgiadinh13 жыл бұрын
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"?
@pricesmith17932 жыл бұрын
Do you have any info on your vim setup or general vim recommendations for golang?
@MarioCarrion2 жыл бұрын
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_59043 жыл бұрын
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
@MarioCarrion3 жыл бұрын
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_59043 жыл бұрын
@@MarioCarrion Thank you for answer! I read about saga pattern and unit of work. I think it can help me too. Big thanks!
@pedroluzio3 жыл бұрын
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)
@MarioCarrion3 жыл бұрын
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.
@pedroluzio3 жыл бұрын
@@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?
@MarioCarrion3 жыл бұрын
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.