Domain design

Abstract

The architect has to map the domain requirements to technical solutions. The main result of domain design is the reference architecture, involving variation points, supporting platform and mass customisation. The reference architecture has to be flexible, evolvable, and maintainable. Its design incorporates the accommodation of future requirements and technology. In particular, the reference architecture changes over time. The domain architect has many interactions with neighbouring sub-processes, i.e. domain requirements engineering and realisation as well as application design. External variability in the requirements has to be designed into variability in the architecture. In addition, technical options introduce internal variability, which has to be incorporated as well. The architects are stakeholders in the requirements engineering process. They provide feedback on what is easy and what is more difficult to vary. Similarly, developers providing the realisation inform the architect where adaptability is most needed. With respect to normal single-system software development, the relationship to application design is different. Application architects use the reference architecture to prepare application development. This means that the domain and application architects together have to find a balance between what is better done at the domain level and what is done at the application level. Over time, this balance changes, as solutions applicable for a single application may become useful for others as well. In addition to the normal architecture issues, variability and reuse have to be solved by the reference architecture. Moreover, the architecture should solve the quality requirements of variability, flexibility, evolvability, and maintainability. For many other quality requirements the architecture has to provide solutions that work for a group of applications, not all of which are envisioned. © 2005 Springer-Verlag Berlin Heidelberg.