This is one of my favorite figures that shows how we do solution engineering in patterns & practices at Microsoft:
Architectural Scenarios
It all starts with a scenario. It has to be a meaningful problem. You can’t evaluate an architecture in a vacuum. In order for us to build useful baseline architectures, we need to pick the right scenarios that flex the right engineering decisions.
Patterns
Patterns are simply problem and solution pairs. In our case, we tend to focus on application, architecture or solution level patterns.
Baseline Architectures
Baseline architectures are skeletal applications. They’re just enough code to show you how to solve the key engineering decisions. The ideal baseline architecture is durable, but evolvable.
Application Block Library
These are reusable components. You can think of these as the cross-cutting concerns and the key application infrastructure hot spots.
Tool Extensions
Once we have a repeatable solution, the next step is to add tooling support to help users with some of the boiler-plate code, choose relevant options, and help configure the solution.
> one of my favorite figures
it’s probably a great diagram to start with for upcoming Microsoft Oslo modeling. The above is a tangible point many will be able to grasp to move into modeling.
It’s a good diagram to start with examples of domain-specific languages, correlating patterns to DSL keywords, correlating functional (storyboards, requirements and use cases) domain-specific languages to technical entities, etc.