“Good Enough” Architecture Part 1 • Stefan Tilkov • GOTO 2020
Vložit
- čas přidán 14. 08. 2024
- This presentation was recorded at GOTOpia November 2020. #GOTOcon #GOTOpia
gotopia.eu
Stefan Tilkov - Co-founder & Principal Consultant at INNOQ
Part 2 available here: • “Good Enough” Architec...
ABSTRACT
In this session, we’ll take a look at some of the ways we can determine whether the development efforts we’re undertaking suffer from too much or too little focus on architecture. We’ll examine a number of real-world examples that are intended to inspire either admiration or terror, and try to find some recipes of how we can get more of the former and less of the latter in our own projects.
What will the audience learn from this talk? How to find the right balance between agile/ iterative/ incremental development, diving right into coding, up-front planning, and continuous architecture [...]
TIMECODES
00:00 Intro
00:32 First statement about architecture
01:33 Second statement about architecture
02:05 Third statement about architecture
02:34 Architecture antipatterns
03:33 Cases
04:52 Case No. 1: Non-extensible Extensibility
11:49 Case No. 2: Perilously fine granularity
20:30 Case No. 3: Horizontal Conway split
27:45 Takeaways
Download slides and read the full abstract here:
gotopia.eu/nov...
RECOMMENDED BOOKS
Simon Brown • Software Architecture for Developers Vol. 2 • leanpub.com/vi...
Mark Richards & Neal Ford • Fundamentals of Software Architecture • amzn.to/3qmELt7
Gregor Hohpe • The Software Architect Elevator • amzn.to/3tY8evH
Michael Keeling • Design It! • amzn.to/37y4OGH
George Fairbanks • Just Enough Software Architecture • amzn.to/3bbjqg3
Nick Rozanski & Eoin Woods • Software Systems Architecture • amzn.to/3ajYjsv
Peter Coad, Eric Lefebvre & Jeff de Luca • Java Modeling In Color With UML • amzn.to/3bVDTHd
Eric Evans • Domain-Driven Design • amzn.to/3tnGhwm
Grady Booch, James Rumbaugh & Ivar Jacobson • The Unified Modeling Language Reference Manual • amzn.to/2OA1Qv1
/ gotocon
/ goto-
/ gotoconferences
#SoftwareArchitecture #Backend #Antipatterns #ArchitectureAntipatterns
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
www.youtube.co... - Věda a technologie
This could be one of the most important video (series) about Software Engineering in 2021.
Great Talk! Thank you, I am looking forward to the next part
Great Talk. The points about over customization and unmanageable configs I'm living through currently. Look forward to pt 2!
Looking forward to Part 2-N!
The talk is very interesting and useful. Especially, an idea about making the full stack teams is perfect. I've just realized that this way to combine people efforts usually leads to success.
Good talk. Waiting for part 2
Stefan, this is great stuff, thank you.
Great talk!
Great Talk!
Thank you.
Great talk Would love to learn about all the other anti-patterns shown at 2:46.
There's always a trade-off in size and number of services in architecture and sometimes we have to start with the simplest way then evolve our architecture to reach the best configuration.
An irrelevant musing on Conway's Law: Perhaps Microsoft's products inevitably become (overly) complicated as a reflection of the organisation of Microsoft's industrial era customers. Moreover, Microsoft's own organisation is influenced by the products and features its customer demand. It's a sort of Conway's Law by Proxy.
btw: One of my favourite speakers. He's also got a lovely speaking voice.
Please please part 2..
Question: I'm with you on the one team setup, just a question so I can hone my argument better, if we go with full stack teams, meaning having both UI devs and backend devs jn the same team, wouldn't the backend devs become blockers within that team trying to provide with APIs? I don't like the whole backend-for-frontend but lots of time the APIs become so prominent in the architecture.
Thanks for the great presentation.
Content wise I like.
One comment I think you need to have a room that has good sound absorption, it sounds like you are in an enclosed room so there's a light reverb in your voice.
Although I am on the side of splitting frontend and backend architectures. Primarily because the front end uses a whole different technology stack. However, what should occur is the migration of thinking of services to do the work and front end acting as a dumb client (though that is usually the starting point and I would still recommend that as a starting point, but also understand that the technical debt on it is high).
Once you get the starting architecture where the communications are established is when you start moving the data out of the service and into the client. But even before that, you should move your data from your core application to microservices that have specific copies of the data. This intermediate stage will then allow you to do the next bit more easily.
The next bit would generally be providing a streaming communication system between the backend and the front end. GRPC allows for that. Having that allows you to push the data to the client device and let it do the work needed there.
Also the other reason why you'd want to separate front and back is the front end development changes per technology or per user role.
But as you noted in 27:00 we set up teams differently from architecture. Teams are *full portfolio* not just front / back, but different logical groupings and the logical groupings morph, though the front and back separation of technology and developers would make sense otherwise each developer would have two laptops one with Docker and one which can run the device emulators.