Design Pattern / Architecture DCI - Data Context Interaction

Creating Neos & Flow
1

A. Intro :slight_smile:

Throughout past discussions and explorations of ideas – during sprints and online calls – about upcoming innovations of Neos, I have encountered together with some of you, in several instances of really hard to solve problems, conceptual challenges and open questions

… e.g. a complexity challenge in implementing privileges / policies and the definition of

  • layers (framework, application, user) and
  • contexts (e.g. ui area, content type, node),

within which the privileges

  • can be defined
  • reasoned about and
  • determined (calculated)

… another example is the possible reimplementation of Nodes / a NodeInterface, in order to make them extensible and the accompanying discussion about Composition-over-Inheritance, protocol of interaction with Nodes etc. — talked about in the recent weekly ESCR call.

… and of course there is more examples, including of code, that wants to be refactored.

B. Observation

Looking at the Flow Framework and Fusion, I am able to see certain concepts (e.g. AOP, Fusion context, Dependency Injection, Late Binding etc.), that are useful in reducing such complexity by dividing up the problem space along suitable axes, already being used in Neos.

I was impressed to learn from @robert, that the very conception of Neos was founded in the desire to make use – among others – of SOLID patterns. Along the lines of this inspiring idealism, and because I am confident it will contribute value to everyone’s programming of / with Flow and Neos – not only in helping solve above mentioned challenges – but in general and at the core …

C. … I would like to introduce to you

an architecture for networks of interacting objects, an intuitive way of thinking about problems, that involve data objects and their interactions within a context — a programming approach, that immensely increases the ability to write understandable code in the form of explicit use cases and increases the programmer’s confidence in correctness of their work, in almost any programming language.

It was invented by Trygve Reenskaug – the same mind, that gave us the MVC pattern.
Data, Context and Interaction give it its name: DCI

For you to see, what it’s all about, I’m including a following example – which is by no means a perfect implementation of DCI – for you to study, as well as a couple of in depth going talks by James Coplien (@jcoplien) and articles.

In essence – in my own words – a context object (e.g. a Money Transfer):

  • contains (Composition)
    • all data objects, that are to perform an interaction (e.g. two Accounts) as Roleplayers, which play a Role
    • the “script” for the interactions between the abstract Roles
    • and their contextual environment
  • initializes everything necessary for the interaction to occur upon its construction (late binding)
  • provides to the outside only methods relevant to the interaction and context (e.g. a MoneyTransfer)

— It’s basically an already aimed and loaded gun (the MoneyTransfer), that only needs to be triggered (call of Transfer method) – with the option of providing an amount of how many bullets to fire (Amount) – everything else is encapsulated away and taken care of within that gun.

— or like a role-play with a stage on which concrete role-players are assigned certain predefined roles and given a pre-written script, that they only have to carry out

A context itself (e.g. a Money Transfer) can also be an object within another larger context (e.g. a Payment for a Product).

Please investigate DCI (using below references) and share

  • if you were already familiar with DCI or some of the concept
  • where in Neos & Flow you see potential for the use of DCI
  • how DCI may contribute to your own programming
  • which concrete problems you’re able to approach differently
    (easier, more elegant, better understandable), using DCI

I would appreciate your feedback.

So, here you go:
one example (see the repo for a full picture):

These are talks, that explain DCI and its use in more depth:

James Coplien - The DCI Architecture: Supporting the Agile Agenda

DCI condensed - A case for contextualized polymorphism,
(How does the human mind work before it gets destroyed by Computer Science degrees and programming languages?)

Trygve Reenskaug - Object Orientation Revisited. Simplicity and power with DCI.

Rickard Öberg - DCI in Practice

Entwicklertag 2016: How Agile and OO have lost their way together - James Coplien

More on DCI
https://www.artima.com/articles/the-dci-architecture-a-new-vision-of-object-oriented-programming

1 Like
2

I knew DCI before and I think it’s a very useful way to think about interactions. As with all concepts it doesn’t fit all use cases, but I think it’s good to have heard of it. I would say the EventSourcing and CQRS code in the future content repository could in parts be described in DCI terms as well.

1 Like
3

@robert, as you are working on refactoring Flow, it may be worthwhile looking into and considering the usefulness of DCI for implementation.
I know you have a soft spot for design patterns :slight_smile:

Which parts of framework are you reworking currently? What is your vision for the Flow of the future?

4

Currently I need to keep my focus on making preparing Flow to be fully compatible with and use features of PHP 8.2. This means refactoring the Reflection Service and Proxy Class Builder, along with some connected parts.

As for the future of Flow, there are a couple of plans, ideas and wishes I discussed at the Neos sprint I’m just returning from. In particular, I’d like to further discuss an architecture based on CQRS, DDD bounded contexts, Doctrine DBAL and a certain way of creating DTOs / Read Models, which I can imagine being useful as a blueprint for not-yet experienced developers, similar to architecture examples that came along with Flow in the past.

Right now, I’m a bit too tired and overwhelmed by the 1,5 weeks of Neos in Berlin, but we can certainly discuss this later on.