Lesson 101 - Components and Root Namespaces
HTML-код
- Опубликовано: 11 ноя 2024
- Software development and software architecture intersect in many ways. One of those intersections is the definition and corresponding implementation of architectural components - the building blocks of an application. In this lesson Mark Richards describes the definition of an architectural component, a root namespace, and explains the concept of “orphaned classes” - classes residing in a root package. While this is a common practice, Mark shows how it can have devastating architectural implications, particularly when migrating monolithic applications to microservices.
Reference Links:
Fundamentals of Software Architecture: www.amazon.com...
Training Classes: www.developert...
Software Architecture Monday: www.developert...
Thanks a lot for this video.. Very informative
I can imagine the arguments for and against this approach but great points made here. When is the "Software Architecture Deep Dive" book being released? 😊 I am making an assumption that a second book is in the works.
Hi Karim, our next book "Architecture: The Hard Parts" published through O'Reilly should be available by summer 2021.
@@markrichards5014 Hi Mark, sounds great, looking forward to it.
Hi Mark, this is a really interesting concept, and I see how it will make the live of both developer and architect easier. One question I have is how you structure modules such as Controllers, Views, etc. In a lot of frameworks by convention they are stored in the same folder/namespace. Do they become components of their own?
If those controllers or views span multiple other components, then you can either put them in their own component (even if its a single class file!), or add it to another component, knowing that the owning component will be efferently coupled to other components the controller accesses.
@@markrichards5014 , if I understand correctly, the structure will look like this for a single file component
- ServiceBla
- Sales
- SalesController
- Marketing
- MarketingController
or alternatively like below if controllers are bundled into a single component
- ServiceBla
- Controllers
- SalesController
- MarketingController
in this case "Controllers" component is coupled to other components that are related to Sales or Marketing.
I would assume it is cleaner to have each controller as part of its own component. I just never seen that happen in the MVC apps I came across in my life :)
Hi Mark,
I am struggling to understand the purpose of this.
From what I understand all this accomplish is a clean separation of modules into components, allowing for easy refactoring into separate services. As a developer, a similar scenario would be to use logical spacing to separate pieces of logic, so it can be easily copied and pasted into functions if needed.
Is organization and ease of refactoring the benefits that this golden rule you mention offers? Or am I missing something else?
Ho Aaron, It's that, plus the ability to govern various architectural characteristics and architecture decisions involving coupling between components. The techniques I introduce in the video not only help with migration, but also overall maintainability, testability, and deployment within a monolithic application.
@@markrichards5014 Hi, thanks for the answer! Can't say I understand it completely, but I definitely understood a bit more. This is probably because I lack experience in large monolithic applications, but we will see as I apply it day-to-day.
Please keep creating these videos!
Is this a full course on software architecture
Hi Ranjith, no, this is just a collection of separate lessons (some of them linked for topics that span more than one video). Full courses are much more organized and have a narrative arc with a nice and even flow.
Sir thank u for ur reply
Knowing only the topics covered in this series is enough to know about the software architecture