Status Updates From Fundamentals of Software Ar...

Chapter 25 is the most interesting and I enjoyed it a lot.

At the end of the book, the author emphasized that all software architecture is a trade-off, also any architecture decision are not binary and fall into a spectrum of trade-offs.

Overall the last few chapters are also barely readable.

The last part of the book is barely readable. The problem is that the author has placed the software architect outside of the developer team, and then spent Chapter 21, 22, 23, 24 to describe how they can work together. From my work expereice, these engineers are from the same team and they usually work together.

I found the these chapter hard to follow.

Part 2 is not very informative, except chapter 15.

Chapter 9 barely scratched the surface of the distributed system. Recently I've read Database Internals's Chapter 8, which done a much better job to describe all problems in less words.

Then the authors started to list all possible architectures. A lot of very shallow discussions, and I only learned a few interesting bit in Chapter 15.

The first part of the book was hard to follow. It is because the the authors spent a lot of time to explain what's a design and architecture, and the reader can be easily lost in the terminology introduced by the book, name a few examples

1. architectural quanta
2. "fitness function"

I found the book scratching the surface on a lot of aspects, and giving very basic example (ordering system, which is too shallow)

The first part of the book was hard to follow. It is because the the authors spent a lot of time to explain what's a design and architecture, and the reader can be easily lost in the terminology introduced by the book, name a few examples

1. architectural quanta
2. "fitness function"

I found the book scratching the surface on a lot of aspects, and giving very basic example (ordering system, which is too shallow)

Already loving this book. I knew it was the right call to get it

5th re-listen update on Jan 12, 2025

Amazing perspective on architecture

🐱

Powolny progress po przerwie

Reviewing the architecture patterns themselves because I thought it was what I most struggled with but looking back at the table of contents, I should review the beginning itself and maybe then the patterns can make more sense!

:)

Sometimes it can be hard to define what architecture characteristics are, and also implicit characteristics, which are termed that because it's hard to get a team to focus on them if they're called "non-functional characteristics". The first law of architecture is that everything is a trade off! I can't remember what the others are, but you never really choose the best architecture, just the worst least one!!!

I'm at Chapter 20 of 24!

Service based, event driven architectures

The service-based architecture is a distributed architecture that scopes services by domain. It is often compared to a microservices architecture, which has a dedicated service (though I should walk a very fine thread as it has not yet been covered)

The microkernel architecture is typically a monolithic, single deployment (although not always), and is typically small as it is restrained in its elasticity and scalability characteristics.
Great examples of this include Tax forms or the Chrome web browser. This style can be coupled to a user interface in itself another microkernel, though this is usually not the case. Plug-in components extend functionality.

Fajna i nie za trudna, a można się doedukować.
Czytam co popadnie póki mam wolne xd

Gave the foundations of architecture styles and then went in-depth on the Layered Architecture style. So it went over topology, layers of isolation, adding layers, and "other considerations"

This time I actually went back and re-listened on some of the material I got lost on. Connascence, or the degree of coupling between programs or modules (I hope I'm getting this last part right) was explained, and an equation to calculate it was given. The degree of efreent coupling / the degree of efreent coupling + affront coupling. The differences between the two is remembered by the "e" in effrent = exit/outgoing

Re-listening

2nd time

This has been a good book. The fundamentals - what the job entails, patterns, soft skills. Pretty well rounded. I've seen comments that criticize it but they seem a bit unfounded - the book isn't supposed to focus on the engineering aspect of it. The book clearly states it'll use terminology but nowhere does it state it would delve deeper into it, they are two different coins!! Perfect for SWEs who want to be a SA.

Diagraming standards and how to present architecture, and the current chapter is about architect personalities: control freak, armchair architect (who hasn't coded in a while or is decoupled),

Risk assessment / mitigation

Moving on to section 3, the soft skills required to be a successful software architect. At the end of section two the microservices architecture was covered, and there's a course on that one being used with React and Node (both JavaScript frameworks).

It's good to know the material covered can be found in lectures that guide you through actually implementing it with a language. Maybe it's shown in the book?

Awesome.

The narrator is going through several different architecture styles for a large (or majority) of the remainder of the book.

The role of an architect is described in contrast with an engineer. Significant differences include: architects need an eagle eye, if you will, to know a large amount of technologies but don't necessarily have to specialize. Their breath of knowledge should be prioritized over depth.

This helps them weigh the different technologies & choose the right one. Architecture characteristics are presented & defined.