Category: Domain Driven Design

Views, Models, & Architectures

Preamble

Views can take different meanings, from windows opening on specific data contexts (e.g DB relational theory), to assortments of diagrams dedicated to particular concerns (e.g UML).

Fortunato Depero tunnels
Deconstructing the Universe along Contexts and Concerns (Depero Fortunato)

Models for their part have also been understood as views, on DB contents as well as systems’ architecture and components, the difference being on the focus put on engineering. Due to their association with phased processes, models has been relegated to a back-burner by agile approaches; yet it may resurface in terms of granularity with model-based engineering frameworks.

Yet, whatever the terminology (layers vs levels), what is at stake is the alignment of two basic scales:

  • Architectures: enterprise (concepts), systems (functionalities), and platforms (technologies).
  • Models: conceptual (business context and organization), analysis (symbolic representations), design (physical implementation).

Views & Architectures

As far as systems engineering is concerned, understandings of views usually refer to Philippe Kruchten’s “4+1” View Model of Software Architecture” :

  • Logical view: design of software artifacts.
  • Process view: captures the concurrency and synchronization aspects.
  • Physical view: describes the mapping(s) of software artifacts onto hardware.
  • Development view: describes the static organization of software artifacts in development environments.

A fifth is added for use cases describing the interactions between systems and business environments.

Whereas these views have been originally defined with regard to UML diagrams, they may stand on their own meanings and merits, and be assessed or amended as such.

Apart from labeling differences, there isn’t much to argue about use cases (for requirements), process (for operations), and physical (for deployment) views; each can be directly associated to well identified parts of systems engineering that are to be carried out independently of organizations, architectures or methods.

Logical and development views raise more questions because they imply a distinction between design and implementation. That implicit assumption induces two kinds of limitations:

  • They introduce a strong bias toward phased approaches, in contrast to agile development models that combine requirements, development and acceptance into iterations.
  • They classify development processes with regard to predefined activities, overlooking a more critical taxonomy based on objectives, architectures and life-cycles: user driven and short-term (applications ) vs data-based and long-term (business functions).

These flaws can be corrected if logical and development views are redefined respectively as functional and application views, the former targeting business objects and functions, the latter business logic and users’ interfaces.

Architecture based views
Architecture based views

That make views congruent with architecture levels and consequently with engineering workshops. More importantly, since workshops make possible the alignment of products with work units, they are a much better fit to model-based engineering and a shift from procedural to declarative paradigm.

Model-based Systems Engineering & Granularity

At least in theory, model-based systems engineering (MBSE) should free developers from one-fits-all procedural schemes and support iterative as well as declarative approaches. In practice that would require matching tasks with outcomes, which could be done if responsibilities on the former can be aligned with models granularity of the latter.

With coarse-grained phased schemes like MDA’s CIM/PIM/PSM (a), dependencies between tasks would have to be managed with regard to a significantly finer artifacts’ granularity.

Managing changes at architecture (a) or application (b) level.
Managing changes at architecture (a) or application (b) level.

For agile schemes, assuming conditions on shared ownership and continuous deliveries are met, projects would put locks on “models” at both ends (users’ stories and deliveries) of development cycles (b), with backlogs items defining engineering granularity.

Backlogs mechanism can be used to manage customized granularity and hierarchical dependencies across model layers

From the enterprise perspective it would be possible to unify the management of changes in architectures across layers and responsibilities: business concepts and organization, functional architecture, and systems capabilities:

EAGovern_EA
Functional architecture as symbolic bridge between business needs and system capabilities.

From the engineering perspective it would be possible to unify the management of changes in artifacts at the appropriate level of granularity: static and explicit using milestones (phased), dynamic and implicit using backlogs (agile).

Fine grained model based frameworks could support phased as well as agile development solutions

Such a declarative repository would greatly enhance exchanges and integration across projects  and help to align heterogeneous processes independently of the methodologies used.

Further Reading

External Links

Focus: Bounded Contexts & Open Concepts

Preamble

Domain Driven Design (DDD), the brainchild of Eric Evans, aims to map out system representations of business entities directly from business concepts and semantics.

Balazs
How to conciliate bounded contexts and open minds (Balazs Szabo)

Four basic tenets are often put ahead to characterize DDD:

  • Layered architectures.
  • Aggregates and threads of continuity and identity.
  • Bounded contexts.
  • Ubiquitous language supporting the communication between business domains and software representations.

If the meaning and benefits of layers and aggregates are widely understood, there is less of a consensus about practical implementation of bounded contexts and ubiquitous languages.

Architecture Layers

All too often, modelers overlook the difference between descriptive and prescriptive models, the former depicting business environments and objectives, the latter their symbolic representations in systems. Unfortunately, this seemingly benign neglect seems to imply that descriptive models have no other purpose than supporting the development of systems, which can subsequently stand on their own. But what may once have been a safe assumption is now a very hazardous one considering that today’s IT systems must be weaved with enterprise environment and accommodate continuously to its changes.

cc
Feeding development processes is not the only purpose of descriptive models.

On that regard Domain Driven Design seems inconclusive: on one hand it insists upon the tie between concepts and implementations, on the other hand it makes a clear distinction between concepts (roots and aggregates), and their use (contexts). Setting DDD layers with regard to enterprise architecture could help to clarify the point.

With regard to software (as opposed to enterprise) architecture, DDD identifies four layers: users interfaces (or presentation), applications, domains (or models), and infrastructures. Of these, the domain layer seems to be the only one unambiguously set apart, definitions of the others leaving room for overlaps; but potential qualms can be easily remedied by introducing formal criteria:

  • Presentation: non shared processing of I/O.
  • Application: shared processing of transient representations
  • Domain: shared access to persistent representations
  • Infrastructure: shared access to services.
Architecture Functional layers understood as PIM artifacts.
Architecture Functional layers understood as PIM artifacts.

Furthermore, these layers are best understood when associated with the platform independent models (PIMs) of the model driven architecture (MDA) framework.

Aggregates & Roots

The distinction between the identity and structure of objects on one hand, features semantics and use on the other hand, is arguably a core tenet of DDD as it brings together objects designs and systems architectures.

With regard to objects design, aggregates to be accessed through a single root (#) guarantee the continuity and integrity of the threads anchoring business entities to their symbolic counterparts.

With regard to systems architectures, features of business entities surrogates can be shared across domains, each according to their own semantics, as epitomized by persons in the example below.

vvvv
Roots anchor identified (#) persons to their symbolic surrogates

Yet, the fact is that approach combines object with aspect oriented designs and its implementation at architecture level could come with serious drawbacks when functional facets are to be shared across domains. That’s where bounded contexts intervene.

Bounded Contexts

Contexts are introduced to conciliate continuity and integrity, managed through aggregates, and semantics and functional accesses, managed through contexts; bounded contexts (BCs) are ones with shared business entities. Adding to the example above, person usually appears in different functional contexts subject to specific responsibilities, with one and only one with explicit responsibility on aggregates (#).

Bounded contexts are used to distinguish between identification and integrity, managed through aggregates, and semantics and use, managed through contexts.
Bounded contexts are used to distinguish between identification and integrity, managed through aggregates, and semantics and use, managed through contexts.

But as sound and useful as bounded contexts may be conceptually, their implementation is mostly entrusted to maps and best practices. Since the way shared business domains are managed by systems is arguably a key success factor of enterprise architectures, the lack of principled implementation schemes leaves the conceptual gap between business domains and software designs unaccounted for. That would be the purpose of ubiquitous languages (UL).

Ubiquitous or Domain Specific Languages.

The explicit objective of ubiquitous languages is to bring under a common semantic roof domain analysis and software design, and so to tie concepts and implementations. But that very endeavor may also be seen as controversial, shallow, and confusing:

  • Controversial: bringing together concepts and implementations appears to contradict OO principles as well as layered architectures.
  • Shallow: the so-called languages (as many as domains ?) are in fact just lists of entities and operations, without grammar or unifying semantics.
  • Confusing: they are supposedly derived from models, which would suggest specificity instead of ubiquity; that understanding would also belie the customary assumption that models are built with modeling languages.

One way out of the conundrum could be to see ubiquitous languages as variants of domain specific ones whose explicit objective is precisely to tie concepts with implementations. But that option would bypass the issue of principled BC design, and more generally the relationship between business domains, systems architectures, and software designs.

The other way would be to forsake ubiquitous (or specific) languages and use instead open concepts and functional patterns.

Bounded Contexts & Open Concepts

Open concepts are modeling artifacts whose semantics can be shared by business domains and systems functional architectures. For that purpose they have to meet standard OO principles:

  • Open-Closed Principle (OPC): open concepts should have no reason to change, they can only be refined. In other words open concepts are meant to be specialized, but not generalized. That ensures that the semantics of sub-types defined by different projects cannot be modified.
  • Substitution Principle (LSP): sets of instances denoted by specialized concepts are subsets of the sets denoted by more general ones. That ensures that individuals are consistently identified across projects.
  • Dependency-Inversion principle (DIP): higher levels semantics are defined independently of lower levels. That ensures that the semantics of sub-types are consistently, but not necessarily uniformly, defined across projects.
  • Interface-Segregation Principle (ISP): semantics and features are congruent, i.e all features are meaningful for whoever is using the concept. That ensures that there is no overlapping of semantics even when subsets of individuals overlap.

Assuming these criteria can be fulfilled, open concepts can be used as a modeling glue between bounded contexts overlaps.

Open concepts for entities (aka roots):

  • Structural inheritance means that the targeted entities (i.e shared between contexts) inherit both structures and aspects: parties are a subset of social agents.
  • Functional inheritance means that the targeted entities inherit all the aspects whatever the identified structure: an organization has all the features of a collective agent but is not necessarily identified as such.
Domains_BOCs
How to consolidate contexts overlaps using open concepts

Open concepts for aspects (aka features):

  • Structural inheritance is equivalent to composition, i.e inherited aspects are bound to domain individuals whatever their structure: symbolic references are an intrinsic component of products but can be used in any kind of domain.
  • Functional inheritance is equivalent to aggregation, i.e inherited aspects are not bound to domain individuals: business roles can combine different ones.

On a broader perspective, using open concepts to consolidate the overlaps between bounded contexts enables the formal verification of models, not only for internal consistency but also with regard to best practices. And best practices can be translated into functional (aka representation) patterns formally defined in terms of open concepts.

Further Readings

External Links