Это видео недоступно.
Сожалеем об этом.
Lesson 187 - Categorizing Architectural Characteristics
HTML-код
- Опубликовано: 13 авг 2024
- There are literally hundreds of architectural characteristics (sometimes called NFRs, or non-functional requirements). As such, it can get quite overwhelming trying to understand what they all mean. In this lesson I’ll show you a way to categorize architectural characteristics, making it easier to know which ones you might need. While no categorization is perfect, I hope The categories I present in this video will help you better wrangle the plethora of architectural characteristics.
Head First Software Architecture: amzn.to/3VNFI0o
Software Architecture Monday: bit.ly/3dadEe3
Fundamentals of Software Architecture: amzn.to/3rgFLjY
Software Architecture: The Hard Parts: amzn.to/3BjMMF2
Thank you. But can you please make a video and explain what's the practical benefit of these categories? How can they be used? Or they are just "nice to know"?
+1 to the question. I have the same question.
Great idea! I'll definitely do that. Categorization helps gain a better understanding of the different kinds of characteristics available, and also breaks down the ones you might want to consider based on your needs (process-based or operational-based)
So neat introduction to the categories! ❤❤❤ There is only one bias suggestion, which presents in all videos 😊 Mark's comparison of testing microservices versus monoliths is flawed. Transitioning from monoliths to microservices makes testing more challenging due to network connections and other integration complexities. Testing a single unit of a monolith should require the same amount of effort or less compared to one testing microservice unit, as the functions are the same but without the overheads.
You are correct - the more services talk to each other the harder it is to test. However, a microservice has a much smaller testing scope than a monolith does, allowing for more completeness (and ease) of testing. For example, running 23 test cases for a microservice is much easier (and faster) than running several thousand test cases within a monolithic system.
@@markrichards5014Thank you for responding to my comment. I would appreciate it if you could share some references or direct me to your previous videos so I can learn more about the topic. I'm still a bit unclear and would like to clarify it. When dealing with 2 components, A and B, creating integration tests that cover their collaboration is essential. These test suites are required for both monolith and microservices architectures. And it's not just a unit test to one component, but integration for the whole system.
Happy to inform that yours truly has bought Fundamentals of Software Architecture yesterday.
Thanks great! Happy reading!
Thanks for new lesson! Portability looks for me like an Operational AC, while Interoperability can be also considered as a Process AC. Am I missing something? )
No, you aren't missing anything. No categorization is perfect, and there is some cross-over. I chose to put portability and interoperability into the structure category just because those characteristics are influenced most by the structure of the system, and don't relate to the classic operational ones (like performance or scalability) in the same way. However, you can certainly place them in other categories as you see fit.
Thanks Mark, just discovered your channel, great content! Questions about security: you classify the security as structural and cross-cutting characteristic. In large companies, this is THE essential one whatever the application, so incurring costs which may be overrated for some. Do you have any framework/tips on how to "adapt" the right level for each product.
Unfortunately I don't. It really involves a cost/benefit analysis for each part of a system or product, and a tight collaboration between the architect and the product team.
Graeat video. Thanks for this and for share you knowledge. Can you make a video or give us some info about comparing differents aspects of operational categories that overlaps with each other? For example, in a microservice architecture, the more responsiveness your system is,, the more you will sacrifice data consistency because you provide data to other services through events instead of send the data synchronously. Thanks!!
Sure, that's a great idea. There are many common tradeoffs, the most classic ones being availability and data integrity / consistency (CAP Theorem), and responsiveness/performance and security/access control.
Am I only a person who hear a low frequency bump sound periodically on Mark's videos? )
I don't hear it, but I might not have the sensitive equipment you do. I think it might be tapping my iPad as I forward the slides.