After a few years focusing on pure software development work, using primarily Microsoft technologies, I started to get an itch to seek something more challenging in a different are of IT. Don’t get me wrong, I love programming, I just wanted to branch out a bit and broaden my skillset. Thankfully my employer at the time allowed me to spend time with our company’s Business Analysts, Team Leaders, Technical Trainers, Project Managers, Software Architects etc. so that I could learn from them and spend time applying this knowledge. Thankfully I found it quite enjoyable, and the exposure to different roles, all of which contributed in their own way to the software development lifecycle, was invaluable. The most interesting by far for me was software architecture.
As with the other aforementioned roles I spent time with the seasoned software architects and learnt from their example. Not to say I agreed with everything they did but it was very informative and helped me develop my own opinions and methodologies.
After architecting a number of solutions, and a desire to pick up a few Microsoft tech manuals, I came across “Microsoft .NET: Architecting Applications for the Enterprise“, written for the seasoned Microsoft developer and/or architect.
I’ve read a few books by Dino Esposito in the past and the recommendations for this particular book had nothing but good things to say about it so I purchased it. And I certainly didn’t regret it.
I think it’s important as a software developer, engineer or architect to always take an objective view of your own work so even though I thought I knew enough about architecting I wasn’t too proud to skip a book such as this. To be honest I was well versed in a good part of what Dino and Andrea cover in this text, however it helped me reinforce my approach in certain areas and fill in a few blanks in others. Maybe I’ll never use certain patterns they covered in the book, or will avoid others completely because of my own personal opinions, but it’s good to be aware of them in case I ever do need them or discuss them with other techs. Plus one section talks about maintainability and I’m so glad I’m not the only one who keeps rambling on about the importance of this particular subject.
Here is an abbreviated version of the table of contents:
- Architects and Architecture Today
- UML Essentials
- Design Principles and Patterns
- Design of the System
- The Business Layer
- The Data Access Layer
- The Presentation Layer
- Final Thoughts
- Mantra #1 – It Depends
- Mantra #2 – Requirements Are Lord Over All
- Mantra #3 – Program to an Interface
- Mantra #4 – Keep It Simple but Not Simplistic
- Mantra #5 – Inheritance Is About Polymorphism, Not Reuse
- Mantra #6 – Not the DAL? Don’t Touch SQL Then
- Mantra #7 – Maintainability First
- Mantra #8 – All User Input Is Evil
- Mantra #9 – Post-Mortem Optimization
- Mantra #10 – Security and Testability Are by Design
I included the “Final Thoughts” section as although it only takes up a very small fraction of the book, compared to the other topics, it gives you an idea of the breadth of the topics covered.
“Microsoft .Net: Architecting Applications for the Enterprise” was written in 2008 and is approximately 460 pages long. Taking a quick moment to check in on Amazon has it with 4.5/5 stars in the USA with 35 reviews, and 4.5/5 in the UK with 11 reviews.
I found this book so useful in my role as a Software Architect (when I’m not wearing a different IT hat) that I thought it worth the time to write a post about it. Some tech books come and go but this is one I usually find myself coming back to – skimming through the odd chapter so that the main points covered remain fresh in my mind.
If you’re wanting to break into the architectural area of software using Microsoft technologies, or currently hold a position as a Microsoft Software Architect, then I’d strongly recommend picking up this text if you haven’t already.