Domain design is the process of developing a design model from the products of domain analysis and the knowledge gained from the study of software requirement/design reuse and generic architectures. [CARDS94] states that "The key to design reuse is to develop and document an architecture that is generic enough for most systems in the domain and that supports the reuse of code components in the domain". The design model represents the generic architecture developed for the domain analyzed and provides the framework for the development of the reusable components in domain implementation.

The generic architecture is represented by an architectural style which is most appropriate for the product family. This architecture defines the computational platform for all applications in the family and provides guiding principles for constructing a generic design. The result is a partitioning strategy for allocating domain features to software elements and a coordination model describing how these elements are activated and share information.

A coordination model defines the activation and communication protocols for software elements that implement the behavior model. A coordination model typically defines the type of interactions allowed among software elements in an abstraction hierarchy and the mechanisms that support the interactions.

A partitioning strategy defines the "legal" software elements (e.g. subsystems, objects,. data types etc.) and how the domain features are allocated to them. Examples of partitioning strategies include allocation by real-world entities, allocation by control processes, allocation by user modes or allocation by objects. Some of these strategies may be more appropriate to one product family than another. For example, flight simulators which simulate aircraft performance are partitioned by the real-world entities present on the real aircraft [CMU/SEI-93-TR-14]. Selection of a strategy in part depends on the major factors of change identified in the domain models.

Applying the coordination model to the domain models, the internal operations of the system are identified. The system mechanisms and their performance parameters are specified. For example, one model may specify that a shared data region is used for communication instead of messages, or that a kernel executive is used instead of rendezvous for activation.

The internal behavior of applications in the product family is formalized in a design specification. This specification describes the internal operations identified in partitioning the domain information and specifies their associated constraints (e.g. definition of error conditions). If applications in the product family are embedded in a hardware system, the constraints (i.e. acceptable states) imposed by the coordination model and hardware are paramount. If the product family is an information system, the business rules are captured as constraints.

A domain-specific software architecture (DSSA) is an example of a generic architecture. A DSSA is a software architecture based on the actual and projected commonalities and differences of applications in a domain[CARDS94]. It is a reusable design component providing the basis for other reusable design and code components. The SEI has built a DSSA from the Movement Control Domain Model by mapping the products of Feature-Oriented Domain Analysis (FODA) onto an architectural style called the Object Connection Architecture (OCA). This produced the generic design for the Movement Control Domain.

Indepth information on software architectures is provided in the Product Line Systems and Software Architecture web pages. These SEI web sites are intended as a starting point and information clearinghouse for anyone interested in software architecture.