While I love this book (I am only 60% done with it), I am self-aware that I tend to get carried away easily and hence I need to read opposing opinions before I make up my final decision, which is what brought me to this post.
Following are a few things with respect to this post and the book in general.
Not well organized
Probably you are right. There might be books that explain things much quicker with clearer examples. But, whenever I read a book, I forget about "time constraints". And that allows me to empathize with the author; to truly understand (as much as possible) the intent behind him saying things the way he says it. Helps me grasp things definitively. Maybe this approach helps you the next time? :)
Anyway, finally, it is up to an individual's taste and style of reading. In that, I agree with your points on organization and lack of examples. However, surprisingly, personally, I have not at all felt that in my reading so far. (I guess that is partly because I could very clearly relate to ALL the "general" problems he was talking about already.)
Irrelevant chapters
I disagree. In my experience, I have found that perspective matters, history matters -- perspective and history about how the software industry evolved. That is the reason why I -- albeit skeptical at the beginning -- enjoyed reading through all the initial chapters, especially the programming paradigms and the stories from the 40s through 60s.
As an example, I find great wisdom in the following lines from the book (paraphrasing).
The principles of good architecture have not changed since the early days of software engineering because there are no new programming paradigms discovered after the 50s.
Why I like it is because remembering this is very helpful whenever you are tempted to think that "I am dealing with such a truly unique system with all new technologies that these design principles do not apply here at all". This thinking is very common in green developers, and this book, if read with the right attitude, humbles them down and teaches them how not to reinvent wheels and rediscover fire. (Hope that made at least some sense. :P)
Architecture's intent
Architecture should clearly relay the intent/purpose/behavior of the system rather than how/on what the system is built on. (My recommendation: Read entire Part V)
This is the most valuable lesson for me (yet). So, even without clear examples, this line can help one validate the effectiveness of a system's architecture diagrams... every single time.
It is all about the business
Business rules, very strictly speaking, are rules that would make or save the business money. Critical business rules are at the highest level and do not change regardless of who performs them (human or machine or types of software). Application-specific business rules are in the next level and specific to the application that was created to carry out the business/work.
The next valuable lesson for me. Of course, the book explains it much better than I have above. But, why I wanted to mention this here was because it now gives me a fresh perspective to imagine/visualize business requirements clearly.
I can now apply this line on any incoming business requirement and imagine, "what if I had to make it happen using actual people? How would I manage all the operations? Whom will I employ? What information (read: data) will I provide to whom. Who will do the calculations? Who will go and deliver the output we produced, and in what format? How do I ensure that my business does not become dependent solely on one person (sounds familiar? Eh? eh? ;)) ? How can I effectively "extend" a part of my business to "external businesses" and that enhances my business over all (read: plugins)? And so on and so forth.
SOLID
I actually skipped SOLID (Part III) entirely because I am already convinced of their benefits. Moreover, the answers to creating (and maintaining, over time) a good architecture does not lie within SOLID alone. It is the combined knowledge of all the concepts, and application of that knowledge, and based on experience and intelligent guesses.
In summary, I guess I would recommend that developers who can spare time to read a novel should definitely read this story book. :)
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Finished reading the book over the weekend. I will definitely agree with you now. More examples would have been better. :D
I also found one other thing funny. As the book says, "architecture should relay the intent/purpose of a system than what it is built on", I could not see this being applied in the Video sales example. Ha! All I saw was presenters, views, interactors, controllers, etc. divided vertically by type of actor. The diagram does say that it is "a preliminary component diagram", but I don't think anyone would have minded if the author provided "detailed component diagrams" for the next 20 pages.
Similar to what you mentioned in the post, all the background history and concepts and terminologies and philosophies finally build up to a simple "preliminary component diagram". Wait what? That... seems a bit... silly, right?
Anyway, this was a great book for me to get clear understanding of the terminologies and concepts in this domain. Next up, the Martin Fowler book you've recommended.
B)(y)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice summary, Blaine.
While I love this book (I am only 60% done with it), I am self-aware that I tend to get carried away easily and hence I need to read opposing opinions before I make up my final decision, which is what brought me to this post.
Following are a few things with respect to this post and the book in general.
Not well organized
Probably you are right. There might be books that explain things much quicker with clearer examples. But, whenever I read a book, I forget about "time constraints". And that allows me to empathize with the author; to truly understand (as much as possible) the intent behind him saying things the way he says it. Helps me grasp things definitively. Maybe this approach helps you the next time? :)
Anyway, finally, it is up to an individual's taste and style of reading. In that, I agree with your points on organization and lack of examples. However, surprisingly, personally, I have not at all felt that in my reading so far. (I guess that is partly because I could very clearly relate to ALL the "general" problems he was talking about already.)
Irrelevant chapters
I disagree. In my experience, I have found that perspective matters, history matters -- perspective and history about how the software industry evolved. That is the reason why I -- albeit skeptical at the beginning -- enjoyed reading through all the initial chapters, especially the programming paradigms and the stories from the 40s through 60s.
As an example, I find great wisdom in the following lines from the book (paraphrasing).
Why I like it is because remembering this is very helpful whenever you are tempted to think that "I am dealing with such a truly unique system with all new technologies that these design principles do not apply here at all". This thinking is very common in green developers, and this book, if read with the right attitude, humbles them down and teaches them how not to reinvent wheels and rediscover fire. (Hope that made at least some sense. :P)
Architecture's intent
This is the most valuable lesson for me (yet). So, even without clear examples, this line can help one validate the effectiveness of a system's architecture diagrams... every single time.
It is all about the business
The next valuable lesson for me. Of course, the book explains it much better than I have above. But, why I wanted to mention this here was because it now gives me a fresh perspective to imagine/visualize business requirements clearly.
I can now apply this line on any incoming business requirement and imagine, "what if I had to make it happen using actual people? How would I manage all the operations? Whom will I employ? What information (read: data) will I provide to whom. Who will do the calculations? Who will go and deliver the output we produced, and in what format? How do I ensure that my business does not become dependent solely on one person (sounds familiar? Eh? eh? ;)) ? How can I effectively "extend" a part of my business to "external businesses" and that enhances my business over all (read: plugins)? And so on and so forth.
SOLID
I actually skipped SOLID (Part III) entirely because I am already convinced of their benefits. Moreover, the answers to creating (and maintaining, over time) a good architecture does not lie within SOLID alone. It is the combined knowledge of all the concepts, and application of that knowledge, and based on experience and intelligent guesses.
In summary, I guess I would recommend that developers who can spare time to read a novel should definitely read this story book. :)
Thanks for the thoughtful comments, Krishnan.
There are plenty of people who enjoyed this book and rated it 5 stars on Amazon so you are definitely not alone in recommending it.
Cheers.
Finished reading the book over the weekend. I will definitely agree with you now. More examples would have been better. :D
I also found one other thing funny. As the book says, "architecture should relay the intent/purpose of a system than what it is built on", I could not see this being applied in the Video sales example. Ha! All I saw was presenters, views, interactors, controllers, etc. divided vertically by type of actor. The diagram does say that it is "a preliminary component diagram", but I don't think anyone would have minded if the author provided "detailed component diagrams" for the next 20 pages.
Similar to what you mentioned in the post, all the background history and concepts and terminologies and philosophies finally build up to a simple "preliminary component diagram". Wait what? That... seems a bit... silly, right?
Anyway, this was a great book for me to get clear understanding of the terminologies and concepts in this domain. Next up, the Martin Fowler book you've recommended.
B)(y)