Ай бұрын
Пікірлер
@dylanliu2466 11 сағат бұрын
Great presentation!
@wahoobeans 2 күн бұрын
So basically, TDD is programming Jesus. Having trouble sleeping at night worrying about everything that could go wrong? Just enslave your mind and write the tests.
@antaraantar2643 6 күн бұрын
Awesome ! Thanks for sharing that knoweldge with us and because it is tremendously simpler (not simple) that any other pattern at first sight it is hard to understand why PA made Developer’s life so much better.
@emmanuelvalverderamos 8 күн бұрын
Very cool talk, concepts that I think are not right, there is no way to do unit tests better than the other. There are solitary tests and social tests and you have to know how to use them depending on the context. Any test should be focused on behavior, whether sociable or solitary, but what he says are poorly done solitary tests. Regarding scope, you talk about scope referring to the scope of your unit tests, but you also have to take into account the concept of bondaury. I also see another conceptual error, unit tests do not have to be tied to a business requirement. Regarding whether someone says that unit tests should be kept in isolation, yes, the definition itself when the term was created, then the same test desiderata also
@ruixue6955 14 күн бұрын
20:08 Book: GOOS
@stevend1070 16 күн бұрын
I don't agree with moving behavior into Enity classes. This ties our domain to the DB and gives less flexibility for changing types and names. I would map the entity into a Member class that does not have any tie to DB.
@InfectedTofu 17 күн бұрын
I would be very careful with team topologies. Initially you correctly highlight that value flow and ability to change are crucial, but then you are throwing those goals under the bus because of team cognitive load. I think the problem of cognitive load is grossly exaggerated and sacrificing change and flow for them is a big mistake. But even worse, my experience has been that teams with specific component accountability suffer more from cognitive load than teams that have shared cross functional accountability over the entire stack. But even without this observation, i wouldn't flip my org upside down and throw away change and flow to tackle cognitive load unless it was very clearly impacting change and flow, not a second before. Clearly defined boundaries are good between the org and the rest of the world (using a 3rd party solution? make a clear boundary for it!) . But within an org, boundaries are sources of bottlenecks, handovers, overproduction, and a plethora of other problems, you even say so yourself early on.
@mehmoodrehman6336 19 күн бұрын
Thanks for sharing, excellent presentation by Kent beck
@sergeypichkurov8757 21 күн бұрын
Huge props for Alistair for everything he has done (and doing) for the industry. However, this hexagonal thing hardly can be named an architecture. IMO that is plus/minus the same egg from a different perspective as the "clean" architecture, or showcase of dependency injection. On the other side, some important concerns are not tackled (and cannot be tackled) with such an approach - state management and persistence, temporal coupling, transactionality. He claims I/O is not leaking - but it's leaking everywhere, as soon as one makes a step away from the "happy path". Switched event feed from JMS to Kafka - and here you go, find yourself scratching your head as to where to place commit. Want asynch jdbc - learn that you've got to redo your db adaptor from scratch, as the original abstraction was a synch one. Drawing parallels with hardware world is more an illusion than abstraction. And in hardware world you've got 1 or 2 complex components with a lot of simple stuff (plumbing) around it - it's not what we expect from scalable software architecture IMO. Testability looks simple on the paper, but as long as you consider that each of the "mocked" components have an associated, independently maintained state, the complexity explodes. And to conclude, I (personally) have big troubles to see how this can be married with modern CBA (cloud-based) and EDA (event-driven). On the paper CBA should be a better match, as it also about components and composition, but in reality those components are infra level abstractions, and lifting some vendor component attractions into the code (like Java) is a huge deal (don't confuse it with IaC vendor libs which are different thing) and doesn't add any value. and EDA also breaks it along the temporal coupling matters (hexagonal is mainly synchronous).
@teleruin8686 22 күн бұрын
Can one adapter connect to multiple port ? Lets say I have an app that I have split into severalt driving ports... Lets say I have one port called "for_managing_customers", and another one called "for_managing_cars". Then I want to make a rest api that manages both Can I then make 1 ApiAdapter that connects to both ports ? Or should I then make 2 ApiAdapters, and somehow merge them in an api gateway ?
@guybrushthreepwood2910 22 күн бұрын
What a legend. Excellent talk. I don't think a lot of people (especially those that bash TDD) realize how good of an idea this is and how rare it is to come up with this way of thinking.
@veganaiZe 24 күн бұрын
To take a shot at answering the QA question... The programmers themselves should design & write programmer tests (aka. unit tests) for both themselves & colleagues (QA) to feel reasonably confident at that level of development (the bottom of the test pyramid). QA should be more responsible for designing & maintaining the upper-half of the test pyramid. It's fine if QA wants to test the durability of the base of the pyramid, and they should, but decent software engineers should be (allowed to be) self-organizing. When defects are found (by QA) they should be reported down to engineering, who will design their own solutions for each issue. (A two-circle Venn diagram, representing programmer vs. QA design & maintenance responsibilities, would overlap in the middle / integration level of the test pyramid.)
@jrgalyen 26 күн бұрын
@Kent Beck, would love if you reach out to Jim Coplien on his alternative to TDD. With it, I think he is ok if we learn TDD like we learn a kata. But moving assertions into code You have TCR (which I dislike). Jim Coplien has something different too. An evolution of TDD
@teleruin8686 28 күн бұрын
I got one question... When you have driven adapters outside the app, and they are mocked up in the tests... Should not the driven adapter-code be tested ? Or should they be tested seperatly ?
@guybrushthreepwood2910 22 күн бұрын
Yes, you definitely want to test the adapters. I normally have integrations test that test each adapter. I also usually have some integration test that covers a complete happy path (but it it's important to point out here that it's a happy path and the goal is not really to test the logic, but just to make sure that all the plumbing works end-to-end).
@alihammadshah 28 күн бұрын
brilliant channel
@ariasalmeida Ай бұрын
Excellent talk !!
@MarianVarga-wr1rl Ай бұрын
I asked about optimistic locking and transactions and @Rob van der Linden Vooren asked a similar thing about propagating context from/to adapters. Unfortunately, the answer is "I don't care". This sounds like an "ivory tower" architecture to me...
@kfsama Ай бұрын
Hi! I'm not really used to this specific approach, but I do try to isolate interfaces and their responsibilities in my work, so what Alistair says landed nicely in my mind. To try to figure out some working design of the interfaces, I'd start by asking questions like this to myself: For passing of the context: is it an important part that should be accessed and used in the app itself? I'll make it a part of each interface then (both driving and driven). Or is it an implementation detail? Then I'd try to delegate this to the supporting libraries, to make it a sideband context and then work on supporting it on all types of the adapters (which can be a tedious task and it would be an easy thing to lose). If there is no way to do that in the language/ecosystem, then only option A is left. For supporting a transaction or distributed transaction: Is it an important part of the app itself? I'd expose the transaction control on the driven interfaces and make some kind of transaction manager your required dependency. Then wire it up in the app configuration, so it would control all the driven interfaces that need that management. Or is it just an implementation detail? Then I'd make the transaction control a part of your adapter that would expose only "Save" method on the complex object to the app and do all the work without exposing the complexity of the actual storage. For optimistic locking: Is it important to the application? I'd expose the "Update" method with both expected and desired state of the object as the parameters and make it properly return the updated state with failure status or success status as a result Is it an implementation detail for which I can figure out the automatic resolver of the conflicts? Then I'd expose the "Update" method with the set of desired changes to the object state What do you think, should these approaches and this way of thinking work?
@guybrushthreepwood2910 22 күн бұрын
I'd think that the question was a bit confusing in the way that it was worded. This thing can be tricky depending on your needs and there might be different takes on it. For example, if you need a transaction for 2 different write operations of the same adapter, you can provide startTransaction() and endTransaction() methods in the port.
@redsea9931 Ай бұрын
24:30 Anyone who doesn't do it every day hasn't understood it either.
@valentinajemuovic 28 күн бұрын
Exactly, we need daily practice to truly understand something.
@theachannel2157 Ай бұрын
What a co-incidence - I got interested in Hexagonal Architecture today and this was streamed yesterday <3
@italo.buitron 12 күн бұрын
Same, i was reading about this one week ago.
@BlindVirtuoso Ай бұрын
Hi Jimmy. Nice one, highly appreciated. Though you didn't mention about bounded contexts, aggregates, etc, so this one is not about domain-driven refactoring.
@BlindVirtuoso Ай бұрын
Thanks Alistair. Nice one, appreciate it. Though you drew an ideal world picture and problems emerge when abstractions start to leak or when a port abstraction boundary is wrong
@kamransaeedi Ай бұрын
Very informative. Thank you.
@TechExcellence Ай бұрын
You're welcome!
@nilanjenator Ай бұрын
Really dissapointing at (kzbin.info/www/bejne/eWaseWN3d9KsmZI ), Kent talks about 'Test'. He is just babbling. There is no reference to those who have spent a lot of time to explain 'test'. Yet, no one has a problem with this. This is the same problem with all the books related to agile, including Agile Testing, which talk about testing. For the record, I think Kent is a great intellectual and has made great contributions to software development. But, he doesn't understand 'test'.
@aplueschke Ай бұрын
Hi @nilanjenator, what are good references on 'Test' in your opinion? Would be interesting for me to contrast it with what Kent is saying. Thanks
@redsea9931 Ай бұрын
@nilanjenator Are you serious? You know he is one of the few global technicians playing this game in god mode. His explanation sounds more than correct and he also explain additionally why he has not renamed this concept. You are disappointed because he argued thoughtfully and not about the facts he have told. I would like you to remind you here, that those Smalltalk guys (such people as Beck and Cockburn corresponds to your comment) have no need to offer monkeys their cigarettes but still remain friendly when their lighters do not work properly right away. With all due respect, your comment is that of a troll and this is a problem of the receiver here, not it's sender.
@nilanjenator Ай бұрын
@@redsea9931 you are right, maybe I wasn't clear. When we are trying to develop a deep understanding of a software, in order to find risk, there is no substitute for using the software in an environment as close to the end-user as possible. If you compare with the design or marketing of physical products, it makes no sense for any delay in using the product/MVP/mockup in order to check fit-for-purpose. To evaluate a software for risk, you must *use* the product. Of course, you can do a lot before the product is developed - thought experiments, what-if scenarios, mock-ups. But, they are not a substitute for actual use of a product. Moving on, TDD does very little in terms of testing. In TDD, you have a test with a *known* outcome. That helps with code design. But that has *nothing* to do with testing. BTW, I still find TDD helpful, in terms of the what-if questions the possible exploration. However, the *test* part of TDD is *not* testing. And the problem is not with the name. It's about educating users to not be under the delusion that that is testing.
@valentinajemuovic 28 күн бұрын
I agree with Kent Beck's definition. In essence, a test is just given some input, we have some processing of the input to achieve some output, and we have expectations regarding the output. That's it, simple.
@nilanjenator 27 күн бұрын
@@valentinajemuovic are you aware of any alternate opinions/definitions?
@tddtv Ай бұрын
For those who have not had the opportunity to work in shops who practice XP. For those who do not yet have a good mentor to learn from. For those of you struggling to find someone to code review your code because you aren't pairing or mobbing just yet. I was there at one point in my career. When I was trying to get into XP, I was alone trying it on real work. I was surrounded by teams that wanted nothing to do with TDD and Craftsmanship at the time. But ChatGPT would have been a neutral buddy to throw questions to, and probably could have pushed me further and saved me hours from searching the net for everything. Being a hard core TDD practitioner I absolutely think Chat GPT and other AI tools can help critique code. It may not be able to hand hold you through TDD like a real person, but you can use it for refactoring ideas, and reviewing production code. Ask ChatGPT to review the code you wrote after your test passes, it can actually give you some really interesting feedback. Be aware that it's not always correct so verify by trying things (go to people's blogs, Fowler, Kent, etc.), but hell why would you not see what ChatGPT has to say about the code you just wrote if you're not pairing or mobbing? I wish I had something like ChatGPT 15 years ago at the time to help review the Production code I just wrote. Some prompts that could be helpful: Was there a simpler way I could have made that test pass? How could I have applied Clean Code techniques on the code I just wrote? Is this code emphasizing Domain Driven Development? How could I write this code in a more Hexagonal architecture approach? Can you see a way I could have written a simpler test here? I eventually found mentors who were already awesome at TDD, then later got into XP shops but man, if I had this, rather than spend all day searching the net, wow would that have been helpful. - Dave Schinkel.
@nilanjanbhattacharya2172 Ай бұрын
No attempt to explore the word 'test' further or to reference those that have??!!! - TDD has nothing to do with testing. TDD is about code design - Test-first is not an *alternative* to test later. Why? When you use a software in a real environment, it is a powerful learning experience. That is critical to think about what can go wrong (tests). - When you TDD, 95% of your time is spent in thinking. The final *test* is almost trivial compared to the thinking that preceded it. - The test is not the outcome of your TDD. Homework: What is the outcome? - Developers are not motivated to use the software (as real users would) in order to think about risk. Either get motivated, or hire a tester. - When talking about testing in agile, stop saying "TDD, BDD, ATDD". Each of those may have an application, but they do not encompass testing. - *Agile* testing is not a thing. Stop the delusion. - If you are a developer and want to emote about testing, please take the effort to read "Lessons Learned in Software Testing". Be familiar with the names Satisifce, Kaner, Developsense, Weinberg. Engage with testers to understand testing.
@chrishoward7976 Ай бұрын
This is a nice intro. Ports and adapters is such an awesome pattern, but you see it again and again that the terminology confuses people (it was evident in the live chat, too). And while I understand the hand-waving away of specific concerns, given that AC will have been using ports and adapters for the best part of a decade now, some real world practical “recipes” and model examples for different stacks could really help.
@TechExcellence 29 күн бұрын
Yes, many developers have been requesting guidance regarding specific concerns about implementing Hexagonal Architecture. Alongside the TDD in Legacy Code series, there are also plans for Hexagonal Architecture in Legacy Code series - to give specific guidance about introducing Hexagonal Architecture. journal.optivem.com/p/tdd-in-legacy-code-transformation
@JakeWilson88 Ай бұрын
Very insightful - best practices reduce unnecessary development costs.
@TechExcellence Ай бұрын
Yes, especially in the long term.
@AimeeSchwartz-l2c Ай бұрын
Great content, as always! Just a quick off-topic question: I have a SafePal wallet with USDT, and I have the seed phrase. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). How can I transfer them to Binance?
@aleksandrdotnet Ай бұрын
Thank you, Vlad Kononov
@TechExcellence Ай бұрын
You're welcome!
@anastasiaIvanova9 Ай бұрын
Great explanation of the concepts with the drawings 🙌
@TechExcellence Ай бұрын
Thank you!
@jelenacupac7 Ай бұрын
Amazing live talk, thanks Valentina! 👏
@TechExcellence Ай бұрын
Glad you enjoyed it!
@valentinajemuovic Ай бұрын
Thanks for your support Jelena!
@TechExcellence Ай бұрын
Here's the link to the slides: docs.google.com/presentation/d/1EQQh99IQXh0sXLJl2qlZ-1elAN7pJEt15nRvfSHKyEM/edit?usp=sharing
@ghulammustafa357 Ай бұрын
@Olaf Thielke is great technologist. Today talk is awesome.
@TechExcellence Ай бұрын
Glad you enjoyed it!
@TechExcellence Ай бұрын
Github repo: github.com/olafthielke/CleanArchitecture
@cdrbvgewvplxsghjuytunurqwfgxvc 2 ай бұрын
Just avoid layers. Simple as that. The result of you instead localizing your code around subjects will end up in about this architecture. The name is bad as it could suggest you should stick with the layers.
@FlorianKrämer-z8p 2 ай бұрын
Thank you for this excellent talk! It is probably the best one I've heard regarding this topic. Is there any tool available that will collect all three metrics (S, V, D), that will automate the calculation for me? I guess no, because I think it will be hard to find the connections for some of the coupling types.
@alessandrofardin9517 2 ай бұрын
Yes
@seethruhead7119 3 ай бұрын
man OOP makes this stuff so overcomplicated this entire architecture just looks like a request handler function anyone that has any experience with express.js for instance has already been using this architecture.
@mustaphab32 3 ай бұрын
isnt this BDD?
@imrepub 4 ай бұрын
next time please add some transparency to the top right TE logo, or move it outside the presentation area
@TechExcellence 4 ай бұрын
Thanks for the feedback!
@senshiougonno7017 4 ай бұрын
loved the exercice ! thank you so much
@zoranProCode 4 ай бұрын
It’s not because I am from Serbia like Cupać but I really don’t know if there is better channel than this one about the TDD! Keep going guys!!!
@TechExcellence 4 ай бұрын
Appreciate it! Glad that you're onboard with TDD 👏
@jcupac 4 ай бұрын
Totally agree!
@evandrobarbosadosreis 4 ай бұрын
Keep doing this amazing work. Great content indeed.
@TechExcellence 4 ай бұрын
Thanks for the support :)
@Jeca299 4 ай бұрын
Great video! 😊
@TechExcellence 4 ай бұрын
Thank you!
@BlindVirtuoso 4 ай бұрын
This is excellent one.
@TechExcellence 4 ай бұрын
Thank you!
@georgesotiropoulos9935 5 ай бұрын
A very nice session on service boundaries and fat messages. However I still prefer to store the OrderDetails on the First Order Microservice, in one place and use a Saga and specific Commands to send specific portions of the OrderDetails Data to each of the rest Microservices in the ecommerce scenario. Otherwise we need to have extra layer of temporal persistency for each microservice (we already have a local-database at each microservice, we propably have a lookup database, and we have to deal now with a new temporary storage ), add on top to implement all these using hexagons and CQRS projecions and the code becomes really-really complex. My two cents......Great session though!
@zoranProCode 6 ай бұрын
Fantastic pragmatic presentation.
@ChicagoDave44 6 ай бұрын
One thing I didn't hear you talk about is using Read Models to avoid the cross-service interactions. I have always professed that a Read Model is generally UI oriented and ignores all boundaries. Then again, I have been talking about Packaged Business Capabilities (UI + API + Data + Events all packaged as one thing) for about 6 years.
@alpsavasdev 6 ай бұрын
I am 20 minutes into the video and I can tell by now that it is awesome, packed with real life examples.
@TechExcellence 6 ай бұрын
Glad you enjoyed it!
@TechExcellence 6 ай бұрын
Here are the slides: www.dropbox.com/scl/fi/jtyb6lmscycau8axkmg5t/ddd-service-boundaries.pdf?rlkey=gxpcxtadgx7iq7c7og4orhizr&e=1&st=a6atkiny&dl=0