Practical architectural patterns

It all started with a book called Design Patterns - Elements of Reusable Object-Oriented Software. Erich Gamma et al. wrote it in 1995. Ever since then it has had a strong impact on object-oriented design and programming.

The idea is to avoid inventing a new wheel every time you need one. Instead, having found a good solution to a recurring problem, you can reuse that solution. You may have to refine it a bit, but then you'd wind up with a new and perhaps better version of it.

Software is not the only craft that can be helped by design patterns. In his foreword to the book, Grady Booch has this to say:

"The importance of patterns in crafting complex systems has been long recognized in other disciplines. Christoffer Alexander and his colleagues may be the first to use a pattern language to architect buildings and cities. His ideas, and the contributions of others, have now taken root in the object-oriented software community. In short, the concept of the design pattern in software provides a key to helping developers leverage the expertise of other skilled architects."

A sizable part of the Certified Software Architect Microsoft Platform program is about patterns. There is a difference, though. The Gamma book is about rather detailed and technical object-oriented patterns. In contrast, the program's patterns are high-level and business-driven architectural patterns. This is because the Gamma patterns are object-oriented, while the program patterns are service-oriented.

To give you an idea of what they are, here's a far from complete list of patterns you'll meet in the program.

  • The Infrastructure of Shareable Information pattern. With this pattern you define Information Services. Each such service is responsible for and keeps master data for one particular information area. Examples of such areas are Customers, Sales Orders, Shipments, Employees.
  • The User Application and Information Services pattern. This is a synchronous pattern with a direct communication between user applications and services. The user applications request data from and send manipulation commands to information services. This is a simple and popular pattern, often used as someone's first architectural pattern.
  • The Service Wrapper and Information Aggregator patterns. These tend to co-exist with the patterns mentioned above. Put them in front of purchased or legacy applications or services that hold some master data. Such applications and services tend to have complex and hard-to-use interfaces. These patterns hides this, making them look like real Information Services.
  • The Capability and Microservice pattern. It's about microservices that support everything a specific business capability needs. It's gaining ground fast, and it comes with a bonus. The capabilities you choose may already exist in your product backlog as epics. And if they don't, there are many reasons to put them there. Read more about this in the Getting the best from users and business stakeholders program highlight.

These are just a few of the patterns you'll find in the program. They can be a good help to your team, getting projects to fly, fast and safely.

Being as business-driven as they are, they align well to the corresponding business structure. This can give your product extra milage. Strong alignment to the business facilities adapting it to a changing business. This, in turn, is bound to make it more sustainable than a not so well aligned solution could ever be.

Certified Software Architect Microsoft Platform Logo