We mourn the loss of Stefan Tilkov. Obituary
Have you heard of data mesh? Are you intrigued by its potential but uncertain how to get started building data mesh and data products? If so, this article outlines a potential approach and delves into the key concepts behind it!
Zweifellos: Softwarearchitektur ist ein kompliziertes Thema. Dennoch können schon einige wenige Techniken helfen, die Architektur in vielen Projekten zu verbessern. Dazu muss man sie aber wirklich beherrschen und anwenden können. Wie kann man das dazu notwendige Wissen möglichst einfach und effektiv erlernen?
You know what a data mesh is? You understand its basic principles? But you don’t know how on earth to get the data product? Then I will show you how to extract your data product from your Domain-driven Design (DDD) artifacts.
Ging es in Teil 1 von „Innovation on Steroids” allgemein um die Innovationskraft von Machine Learning und die Identifizierung von ML Use Cases, beschäftigen wir uns im zweiten Teil mit der Frage, wie wir herausfinden, wo sich der Einsatz von ML/AI lohnt und wie wir danach strukturiert vorgehen.
Immer mehr Firmen setzen auf die Innovationskraft von Machine Learning und KI. Aber nicht jedes Problem lässt sich mit dem Einsatz von ML-Technologien lösen. Wie also kann man geeignete ML Use Cases identifizieren?
Domain-driven design (DDD) is a useful approach that provides excellent guidelines for modeling and building systems, but it is a means to an end, not an end in itself. While the concepts are valid, you lose a lot if you limit yourself to using them only: There actually is a life beyond DDD.
If you know how to classify the concepts of DDD correctly, it will be easy to achieve good results - and there is a structured approach to achieve that!
In diesem Blog-Post visualisiere ich ein regelrechtes Schlamassel mit Hilfe von Wardley Maps und Elementen aus dem strategischem Domain-driven Design.
Large complex projects are difficult to manage. Software release trains are one solution to coordinate such projects. But the approach is not a great fit for self-organization and modern management ideas.
Quality Storming is a workshop for the identification of quality requirements based on a quality model, for example ISO 25010, using methods and ideas of Collaborative Modeling, which is popular in the Domain-driven Design Community. An important aspect in this context is a cross-collaboration of different stakeholders and skill sets.
Some time ago I was looking for some simple, lightweight tool to document a complex, modularized model. I was not able to find anything that fits my requirements or expectations, so I came up with my own idea. Today, a good 15 months later, I want to introduce it to you.
Software-Entwicklung unterliegt schon immer Hypes. Im Moment reden alle über Microservices und Cloud-native. Aber helfen diese Ansätze wirklich weiter?
The onion architecture is an established approach to structuring applications.
Why domain events and event sourcing should not be mixed up.
Architektur-Katas sind ein sehr interaktives Trainingsformat. Sie eignen sich hervorragend, um Domain-driven Design (DDD) zu vermitteln.
Verwendung von Stereotypen im Code als Basis für ein gemeinsames Architekturverständnis - und mehr
3 Gründe, weshalb Onion Architecture für die Umsetzung von Bounded Contexts nach Domain-driven Design besonders geeignet ist.
Abstractions from category theory can be powerful. But there are reasons why you may want to keep your domain model free of them.
Das Buch Domain Driven Design, welches Eric Evans vor gut 13 Jahren publizierte, galt schon seit jeher als herausragende Referenz für die fachlich getriebene Modellierung von IT-Systemen. Mit dem Einzug von Microservices erfährt Domain Driven Design eine Renaissance, denn die beiden Ideen lassen sich wunderbar miteinander kombinieren. Im Laufe des Artikels werden Sie kennenlernen, wie Sie mit Hilfe der Ideen von Domain Driven Design technisch wie fachlich tragfähigen Microservice Landschaften entwickeln können.
Find us on
