#coplien2000

　マルチパラダイムデザインの立場からは、正の可変性は好ましい設計の形態だといえる。正の可変性を示す場合には、フォーマリズム（formalism, 形式手法）で設計をサポートできることが多い。例えば、継承に正の可変性を導入するときには、Liskov置換原則（Liskov substitutability principle）を用いることができる。しかし、負の可変性に対しても、マルチパラダイムデサインのアイディアを適切に組み込むことができる。その際には、「キャンセルを伴う継承」などの既存技術を使うことになる。この課題の場合の最も直截的なアプローチは、負の可変性に沿ってドメインをサブドメインに切り分けることである。これよりも上級の技法を使えば、#ifdefを適切に使うことを始めとして、6.11 節などで説明する汎用解を導くことも可能である。

No single partitioning can capture all of the important structure of a complex system. Complexity is proportional to the number of distinct, meaningful partitionings (or views) of a system.

Design is the process of aligning the application domain structures with suitable solution domain structures.

If the first level of architecture is a gross partitioning following application domain criteria, the second level of architecture creates abstractions supported by solution domain structures such as those supported by the programming language.

An important design step is to align the application domain structure with the solution domain structure.

Multi-paradigm design beats the application and solution domains against each other to converge on a structure that balances the forces of each.

A domain often can be captured using conventional administrative constructs such as subsystems (as in [Booch1994]). However, domains are logical units of design and may not always map onto the contiguous bodies of code that usually define a subsystem. (An example follows in Section 4.3.) Domains may even overlap. A common example of this from object-oriented programming is the multiple dispatch problem. Consider the code that outputs the contents managed by the TextBuffers domain to a file managed by the PersistentStorage domain. Which domain "owns" the code? The code structure and algorithms depend on both domains. It is also important to note that not all subsystems are domains; subsystems are traditionally administrative units of code, not logical units of design. For example, enterprises may choose a domain to suit market interests or even market perceptions of system modularity and configuration even if the domain touches many parts of the code. Making the domain a first-class concern makes it easier to manage its evolution.

Second, the thesis generalizes the classic domain engineering model, commonly based on scope, commonality, and variation (SCV), by adding the dimension of relationships between domains (SCV + R). It generalizes parameters of variation beyond a model based on parameterization or macro substitution to a more full-fledged model where application engineering can be viewed as a functional mapping where both the parameters of variation and the artifacts of design are themselves domains. This generalization of the treatment of domains allows reasoning outside individual domains about the relationships between them during design. This is a central issue of system software architecture.