diff --git a/get-started/assets/concepts/hexagonal-archritecture-origin.png b/get-started/assets/concepts/hexagonal-archritecture-origin.png new file mode 100644 index 0000000000..bafeced942 Binary files /dev/null and b/get-started/assets/concepts/hexagonal-archritecture-origin.png differ diff --git a/get-started/concepts.md b/get-started/concepts.md index 5649905998..7d46dc852d 100644 --- a/get-started/concepts.md +++ b/get-started/concepts.md @@ -5,26 +5,26 @@ status: released # Core Concepts of CAP Cloud Scale by Design {.subtitle} - [[toc]] @@ -43,7 +43,7 @@ The CAP framework features a mix of proven and broadly adopted open-source and S The major building blocks are as follows: - [**Core Data Services** (CDS)](../cds/) — CAP's universal modeling language, and the very backbone of everything; used to capture domain knowledge, generating database schemas, translating to and from various API languages, and most important: fueling generic runtimes to automatically serve request out of the box. - + - [**Service Runtimes**](../guides/services/providing-services) for [Node.js](../node.js/) and [Java](../java/) — providing the core frameworks for services, generic providers to serve requests automatically, database support for SAP HANA, SQLite, and PostgreSQL, and protocol adaptors for REST, OData, GraphQL, ... - [**Platform Integrations**](../plugins/) — providing CAP-level service interfaces (*'[Calesi](#the-calesi-pattern)'*) to cloud platform services in platform-agnostic ways, as much as possible. Some of these are provided out of the box, others as plugins. @@ -90,16 +90,16 @@ In a first iteration, it would look like this in CDS, with some fields added: ::: code-group ```cds [Domain Data Model] -entity Authors { +entity Authors { name : String; books : Association to many Books; } -entity Books { +entity Books { title : String; author : Association to Authors; genre : Association to Genres; } -entity Genres { +entity Genres { name : String; parent : Association to Genres; } @@ -608,24 +608,24 @@ So, in total, and in effect, we learn: -The *[Hexagonal Architecture](https://alistair.cockburn.us/hexagonal-architecture/)* (also known as *Ports and Adapters Architecture/Pattern*) as first proposed by Alistair Cockburn in 2005, is quite famous and fancied these days (rightly so). As he introduces it, its intent is to: - -*"Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases"* {.indent style="font-family:serif"} +The *[Hexagonal Architecture](https://en.wikipedia.org/wiki/hexagonal_architecture_(software))* (also known as *Ports and Adapters Architecture/Pattern*) as first proposed by Alistair Cockburn in 2005, is quite famous and fancied these days (rightly so). He introduced it back then with the following opening statement and illustration: -... and he illustrated that like this: +*"Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases"* {style="font-family:serif; font-size:115%; padding:0 44px"} -![Hexagonal architecture basic.gif](https://alistair.cockburn.us/hexFig1.png) +![Hexagonal Architecture original illustration by Alistair Cockburn](assets/concepts/hexagonal-archritecture-origin.png) -In a nutshell, this introduction to the objectives of hexagonal architecture translates to that in our world of cloud-based business applications: +We can translate that to these objectives in our world of cloud-based business applications: > [!tip] Objectives of Hexagonal Architecture > > - Your *Application* (→ the inner hexagon) should stay ***agnostic*** to *"the outside"* > - Thereby allowing to replace *"the outside"* met in production by *mocked* variants > - To reduce complexity and speed up turnaround times at *development*, and in *tests* ->
→ [*'Airplane Mode' Development & Tests*](features#fast-inner-loops) > -> **In contrast to that**, if you (think you) are doing Hexagonal Architecture, but still find yourself trapped in a slow and expensive always-connected development experience, you might have missed a point... → the *Why* and *What*, not *How*. +> -> See also: [*Inner-Loop Development & Tests*](features#fast-inner-loops) +> + +In contrast to that, if (you think) you are doing Hexagonal Architecture, but still find yourself trapped in a slow and expensive always-connected development experience, you might have missed a point... → the *Why* and *What*, not *How*. diff --git a/package-lock.json b/package-lock.json index 621a69b1be..d68a10212d 100644 --- a/package-lock.json +++ b/package-lock.json @@ -1,12 +1,12 @@ { "name": "@capire/docs", - "version": "2026.4.2", + "version": "2026.4.3", "lockfileVersion": 3, "requires": true, "packages": { "": { "name": "@capire/docs", - "version": "2026.4.2", + "version": "2026.4.3", "license": "SEE LICENSE IN LICENSE", "devDependencies": { "@cap-js/cds-typer": "^0", diff --git a/package.json b/package.json index 34d6137de1..657b198a78 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "@capire/docs", - "version": "2026.4.2", + "version": "2026.4.3", "description": "Capire on VitePress", "type": "module", "scripts": {