Видео

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.

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.

Yes

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.

isnt this BDD?

next time please add some transparency to the top right TE logo, or move it outside the presentation area

loved the exercice ! thank you so much

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!!!

Keep doing this amazing work. Great content indeed.

Great video! 😊

This is excellent one.

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!

Fantastic pragmatic presentation.

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.

I am 20 minutes into the video and I can tell by now that it is awesome, packed with real life examples.

Here are the slides: www.dropbox.com/scl/fi/jtyb6lmscycau8axkmg5t/ddd-service-boundaries.pdf?rlkey=gxpcxtadgx7iq7c7og4orhizr&e=1&st=a6atkiny&dl=0

Thanks Adam for the awesome session!

Designing a UI for Microservices: go.particular.net/tech-excellence-ui-2 Service Oriented Architecture: go.particular.net/tech-excellence-boundaries-2

This architecture has been around for over 20 years in the modular monolith/modular client. What this video really shows is how little most developers really understand about software architecture and how poorly it seems to have been taught for a long time.

Hexagonal Architecture should just be called what it really is, to avoid so much confusion. What it really is a way to organize code based on the concepts of Input or driver ports and Output or driven ports. Input ports are driven by the users or the app and they drive the application, Output ports are driven by the application and they drive interactions with external systems. That's it. Just some ports. How you organize your projects is not prescribed. You only have to call your inputs and outputs ports and abstract them away however you see fit, so that you can focus on testing the app's behavior based on how it's driven.

I used already Vertical Slice architecture at the beginning of my career, it was then known as Big Ball of Mud

The biggest advantages of using vertical slice architecture is FEWER MERGE CONFLICTS!

People that have had to face the difficulties of not having taken the right micro decisions at the right time, will totally understand this talk and even have some flashbacks, 😹😹

This is the Gilded Rose github repo: github.com/emilybache/GildedRose-Refactoring-Kata

I hope you end up using Mock Service Worker instead of mocking window.fetch... will have to watch to the end and see, because I don't like having to dirty the API adapter by injecting what is basically an http client. It might make sense in C# but in JS world you have things like window.fetch or axios and their interfaces are not compatible, unless you abstract them yourself and create a common interface.

23:44 I find the IBAN validation API adapter a bit too complicated. You shouldn't need a closure to cache the IBAN to be validated. You could just create an Adapter class or object that would contain IBAN related functions like validating an IBAN, extracting encoded information from that IBAN and so on. This would mean less mallocs to just validate an IBAN. Just have a singleton adapter and functions you can directly call on it, like `validateIBAN(iban: string)`.

I've discovered the same architecture, in the same way you did. And, by experience, do not reuse code between handlers. There is nothing wrong on having copied/pasted code. Keep in mind modifications will come per feature, so, probably, this code will need to evolve independently, and the duplicated code will not be duplicated any more.

Here's a link to code demo: github.com/javisan81/hierarchy

Thank you for sharing this perspective on microdecisions in software engineering! The concept of making small, specific decisions rather than tackling problems overly complexly really resonates with me. I believe this minimalist approach can lead to cleaner, more maintainable, and easier-to-understand code. Definitely something to consider in a product!!! I see Agile in action here, as it aligns well with the iterative and incremental approach of microdecisions.

so you went from Controller -> Service -> Repo to Controller -> Handler -> Service -> Repo xD great

He didn't invent VSA. He formalized it. VSA is described in the Clean Architecture book by that old guy, uncle Bob or something like that. 😅 Joke aside I don't know for sure if it's even older than that or who's described the idea first.

Fantastic presentation, thank you so much for putting this together. Great examples in a real world scenario. Very clearly demonstrated the pitfall of relying on coverage, and the confidence you can get by utilising mutation testing. I’m definitely going to give Stryker a go in my projects.

Thanks for the great talk and answers to my questions!

Here's the link to the code demo github.com/dmoka/MutationTestingMeetup

Thanks for your video and GitHub demo project, this is what WE(I believe WE not just me) want, a real-life app component TDD step by-step.

Great talk Jonas, thanks for the explanation!

Enjoy the entire session. Learn so much. It increase my knowledge about clean architecture

It was amazing session

Superb

Amazing session!!

Great Explaination.

Excellent talk and demo.

Pierre really is the GOAT

Amazing discussion, thanks guys!

Great presentation! Jimmy mentions on 59:00, that they've built a "Unit of work" for a data storage that does not support it out of the box. Are there any examples available online?

It was an interesting session, hope you can make a next one as a following session with practical part(implementation wise)

Hello people, great video . Why is the validation of the isbn in the application side , is it not part of the business domain?

I think a useful distinction is that unit tests should run in a single process. As soon as you've got multiple processes involved, things get slower, less deterministic and harder to debug.

I love the meta discussion about learning!

always a pleasure to follow you Michaël Azerhad