OREILLY - System Design Fundamentals

[TUTProfessor]

TUTProfessor submitted a new resource:

OREILLY - System Design Fundamentals - Learn software design from the legendary architect Juval Löwy.

3 Hours of Video Instruction

Learn software design from the legendary architect Juval Löwy.

Over the past 20 years, Juval has led the industry in architecture and project design. Some of his ideas, such as microservices, serve as the foundation of software design and development.

In this dense LiveLessons video Juval Löwy explains his approach to system analysis and design, using volatility to decompose a system into its comprising...

Read more about this resource...

 

[tukumish]

@dikk Is this any good? Please compress and share if it is.

 

[dikk]

@dikk Is this any good? Please compress and share if it is.

Go ahead - it seems to be a concise, good course. And the guy uses a thinkpad not a macbook... So it must be good, right?!

Spoiler: link on zippy, only ~ 160mb compressed

You don't have permission to view the spoiler content. Log in or register now.

 

[tukumish]

@dikk Thank you

 

[learningquest]

Thank you for this

 

[almanesa]

Have seen 2 chapters, turned out that those bad reviews on O'Reilly website for this course are correct:

1. Examples from other domains that do not translate 1-1. A house and software architecture is very different. S/W tends to keep changing houses do not. Examples could have been more real and fewer.

2. Though he says functional decomposition is bad, the final output is functional as well.

3. For 'volatility decomposition' we should be aware of what is volatile and to a large degree we do not know what is until business needs move in that direction.

4. Building for volatility translates to building against YAGNI princpile.

says a lot about what not to do, but little about what to do and how to do. so confusing and weak arguments

1. He is pushing something he calls Volatility-Based Decomposition. After an unnecessarily long explanation of what this is supposed to be, it is clear that it is Functional Decomposition. (Most of the unnecessarily long explanation consists of him telling you why he doesn't like Functional Decomposition, so this makes the whole experience bizarre.) There is a significant amount of straw-man argument in his examples. He presents really poor functional decomposition and then tears into it. But his "volatility" alternative appears to me to simply be functional done better.
- 1a. I agree with his guidance to consider:
----I.) what will change for a particular customer over time and
----II.) what will be different among various customers at the same time. That's a good idea.
2. His examples are a bit off. He tries to apply thermodynamics to software architecture and the specification of requirements, but thermodynamics describes physical systems, not software architecture. Then he uses an example of a notional securities-trading platform but his understanding of the finance industry seems to be shallow. At one point, he describes unit testing as nearly useless, simply because unit testing is not integration testing (also, he confuses regression testing with integration testing). It would be correct to say that unit testing is necessary but not sufficient.