It varied greatly - from terrible "pile of mess" code to nice neat code bases. And I don't mean uncle Bob's "clean architecture" only, but rather more generalized "good architecture" or "good design". Anything that makes code/system flexible, maintainable, sustainable for evolution, etc. Why is that so - it's a different huge discussion. But if you're just asking from the perspective of newcomer, developer who starts his career, then YES, learn it as much as possible, it's very important for beginner to be familiar with good architecture principles. It's good both for interviews, and for your first several months of work. You'll learn it one way or another anyway, but if you come prepared it will make you more productive during first few months. And by "productive" I mean that it will be easier to understand existing code and roles that units play there.
Awesome, good to know. For me hexagonal architecture made most sense.
Then I recommend you to get familiar with actor model) I'm a big fan of actor model myself. It's has many similar ideas to hexagonal architecture, though driven by totally different means. You can think of actors model as hexagonal architecture, where components are called actors, and they can interact with each other only with messages (i.e. it's specialized "port" in terms of hexagonal - only serialized args, and only async communication), and actors can run anywhere and in any numbers. So it is also very loosely coupled, even more loose than hexagonal, plus it's infinitely parallelizable.
I've just watched a video on it (https://www.youtube.com/watch?v=ELwEdb_pD0k), sounds interesting. Did it explain the concepts correctly? Concurrency is interesting to me, but for now I can only make baby steps with it. This stuff can really mess with your head. I do implement my project with WebFlux and R2DBC which I find fun to work with but also frustrating at times, today I've spent like three hours only to find out that I was using hot publisher instead of a cold one 😁.
Yep, the video looks good, explains things correctly. They didn't mention important benefit though - loose coupling. And example of private state with account balance is total shit, pardon my French, it has nothing to do with real world, you'll never have actors each storing someone's account balance. I highly recommend to read "java concurrency in practice" by Brian Goetz. It's hard to find a better resource about concurrency than this book. But this is a long road, proper learning of concurrency and parallelism will take time. It better be started a little bit later, after you get your first job and get your first experience (at least half a year). In standard spring boot web applications you won't need to deal with concurrency. Even in webflux if you will do things properly. And nobody in their sane mind will give tasks that require concurrency knowledge to inexperienced juniors. Yeah, they like to ask questions about "synchronized" and "volatile" on interviews, some old-schoolers can even ask about "wait/notify", but to be honest answering interview-like questions about that does not require solid knowledge. Basic knowledge should be enough. What I can recommend - avoid hot publishers, you won't need them in 99% of cases. And those that you'll need, will be just results of ".share()" or similar operators. I.e. they will work for you intuitively. Custom made hot observables are very rare, off the top of my head I can think of two cases - mouse click publisher, and something like one-to-many notifier in web-applications like rss. In simple cases when there is incoming request and you need to do work only when that request comes in, you won't need hot publishers
Hey man how are u🙄...u think using akka and its actor model is good way to prevent race-condition vulnerability in this senario? Imagine i have a method like this Public void test(){ If(walletHasEnoughMoney()){ NewBalance=oldBalance-amount UpdateUserBalance() } }
Hey man how Are u❤️ I have this method How to prevent race-condition vulnerability in this senario? Public void test(){ If(walletHasEnoughMoney()){ NewBalance=oldBalance-amount; UpdateUserBalance(); UpdateDB(); } } Methods "walletHasEnoughMoney()" and "UpdateUserBalance()" are grpc call so i cant use optimistic locks on hibernate on my microservice And UpdateDB(); is DB query
No, optimistic locking can't be used here. Here, compared to your previous question/example, you have *DISTRIBUTED* update operation. Welcome to the world of the most painful downside of distributed systems. Optimistic locking works only in this scenarios: // tx start (1) read optimistic version flag(s) (2) read any necessary data (3) prepare update request (4) make ATOMIC update + only if version flag(s) are same Crucial part is "atomic" in step 4. The whole idea of optimistic locking is based on that ability to make atomic update conditional update. Redis allows to do it with its watch/multi/exec. Classic SQL databases allow to do such conditional updates atomically on single records. Many NoSQL dbs also allow that. But this condition (4) does not hold true for *distributed* systems. In your specific case, you have compound update operation: (1) UpdateUserBalance() - remote system call (2) UpdateDB() - db call You need to make it atomic (it either completes; or if it fails data state stays like this operation never attempted). There's no any mechanism that out of the box supports it (like Redis/SQL/DB/etc.). Moreover, since it's distributed compound *UPDATE* operation, using distributed locks won't be enough here - you need to have *transactivity* here for case if operation (2) fails, you have to roll back operation (1). Long story short, it's a pain, and there are several solutions. You need to implement some distributed transaction mechanism (term to google is "distributed transactions"). I recommend to not go with two phase commit or similar patterns. I highly recommend to use saga, it's much better in a long run - it's simpler to understand, simpler to implement, and is much easier to keep your system loosely coupled when it grows.
Thankssssssssss man ❤️❤️ your answer really helpd
You're welcome. Also keep in mind that besides benefits, every distributed transaction pattern has very important drawbacks and limitations that may be crucial for the business requirements of your system. For example, saga pattern that I suggested is not a silver bullet, it has its main limitation - it doesn't give strong consistency guarantee, which may be a big NO for your business requirements. Also the solution you pick for distributed transactions will have a HUGE impact on architecture. So pick it very wisely
I will...and thankssssssssss for your advice ❤️❤️
Обсуждают сегодня