Related Concepts

Following is a discussion of CAP in context of and comparison to related concepts.

Domain-driven Design

CAP greatly supports Domain-driven Design by placing the primary focus on the problem domain, providing CDS as a powerful language to capture domain models and thereby facilitates close collaboration between domain experts and developers. CAP’s core concepts fit well to the DDD counterparts of Entities, Value Objects, Services, and Events.

In contrast to DDD however, CAP prefers a strong distinction of active services and passive data; for example, there’s no such thing as instance methods of entities in CAP. Moreover, CAP stays at a more axiomatic level of key concepts: the DDD concepts of Repositories, Aggregates, and Factories intentionally don’t have first-class counterparts in CAP, but can be realized using CAP’s core concepts.

Event Sourcing

CAP can be combined with Event Sourcing patterns, that is, by tracking events in an event store, like Apache Kafka, instead of maintaining snapshot of data in a relational or NoSQL database. Currently there is no out-of-the-box integration to such event sources is provided (we may do so in near future), however this can be easily done in projects by respective service implementations using CAP’s built-in capabilities to emit events and consume events.


Similar to CQRS, CAP strongly recommends separating write APIs from read APIs by defining separate, single-purposed services. CDS’s reflexive view building eases the task of declaring derived APIs exposing use case-specific de-normalized views on underlying domain models. Service actions in CAP can be used to represent pure commands. There is no restriction to ‘verbs-only’ dogmas in CAP though, as CAP focuses on business applications, which are mostly data-oriented by nature, hence frequently ‘entity/noun-centric’.


CDS borrows reflexive view building from SQL to declare derived models and APIs as projections/transformation of underlying models, such as domain models. CQL is based on SQL DML to allow direct mapping to SQL databases. However, it extends SQL by Associations, Path Expressions, and Nested Projections to overcome the need to deal with JOINs all over the place. Instead, these extensions allow working with data in a rather structured document-oriented way.


The previously mentioned extensions in CQL feature both, modeling of nested document structures as well as view building and querying using navigation instead of cross products, joins and unions. This actually brings CDS close to the concepts of NoSQL databases, with the data models playing the role of schemas for validation. Although, CAP currently does not provide out-of-the-box support for concrete NoSQL databases, it is easily possible to do so in project-specific solutions.

Relational Model

While CDS extends SQL and the relational model by means to describe, read and write deeply nested document structures (see relationship to SQL below), it stays compatible to the principles of relational models with a specified mapping to relational databases.

Entity-Relationship Modeling

CAP employs proven basics of Entity-Relationship Modeling for capturing the conceptual data structures of a given domain.

Functional Programming

Similar to Functional Programming, CAP promotes a declarative programming paradigm, which captures domain knowledge and intent (what) declaratively as much as possible, instead of writing imperative boilerplate code (how). This is to automate many recurring tasks in a best practice fashion. Also similar to functional programming, and in contrast to object-oriented and object-relational approaches, CAP promotes the distinction of passive data (~immutable data) and active, stateless services (~pure functions).

In addition, CAP features queries as first-class and higher-order objects, allowing us to apply late evaluation and materialization, similar to first-class and higher-order functions in FP.

Aspect-oriented Programming

Aspects in CDS are borrowed from AOP, especially Mixins. With that, CAP greatly facilitates separation of concerns by “…factoring out technical concerns (such as security, transaction management, logging) from a domain model, and as such makes it easier to design and implement domain models that focus purely on the business logic.” (source: wikipedia)

Object-relational Mapping

CAP and CDS are not ORM. Instead, we prefer querying using CQL to read and write data, which allows to declaratively express what data one is interested in by means of projection and selection instead of loading object graphs automatically. Result sets are pure REST data, that are, snapshot data representations. One reason for that is the assumption that the lifetime of object cache entries (which are essential for ORMs to perform) frequently is in the range of milliseconds only in case of REST services.

Business Object Patterns

Business Object Patterns promote the notion of active objects, which provide instance methods to modify their internal state. In contrast to that, CAP promotes a strict separation of passive data, read and exchanged in RESTful ways, and pure, stateless services. (→ see also relationship to Functional Programming above)

Hexagonal Architecture

CAP’s service architecture is designed with same ideas in mind as the blueprints of Hexagonal Architecture (or Onion Architecture, or Clean Architecture). With that, CAP facilitates projects that choose to apply the principles and designs of those architecture patterns.