Principles and Patterns of Application Architecture | Home

Designing a software system is challenging because it requires you to focus on today’s requested features while ensuring that the resulting system be flexible enough to support changes and addition of new features in the future. A lot has been done in the IT industry to make a systematic approach to software development possible. Methodologies, design principles, and finally patterns have been developed to help architects and software engineers to envision and build systems of any complexity in a disciplined way.
This class aims to provide you with a tutorial about software engineering with a particular focus to the .NET space. The syllabus includes basic principles that should always inspire the design of a modern software system and then moves on to discuss principles and practices of object-oriented design. Along the way, patterns and idioms are introduced as well as pearls of wisdom regarding requirement-driven design that affect key areas such as testability and security. The class also includes busy developer’s overview of UML, testing, and refactoring.
Attendees will first learn to recognize signs of bad design in code that lead to software fragility and resistance to changes. Next, attendees will go through fundamental design principles such as cohesion, coupling, single-responsibility, separation-of-concerns and basic principles of object-oriented design including Open/Close, Substitution, and Dependency Inversion.
It is guaranteed that by fulfilling good principles, every software engineer can craft a good design that matches requirements and is maintainable and extensible. A seasoned development team, though, will do more than just applying effective design principles over and over again. The team, in fact, will certainly draw from the well of experience any solutions for similar problems that worked in the past. Using these building blocks, known as design patterns, is usually more effective and faster than starting from scratch. Design patterns, though, should never be interpreted dogmatically. The good designer, therefore, won’t code to a given pattern, but let the pattern emerge instead through refactoring.