Featured in Architecture & Design

Monal Daxini presents a blueprint for streaming data architectures and a review of desirable features of a streaming engine. He also talks about streaming application patterns and anti-patterns, and use cases and concrete examples using Apache Flink.

Featured in AI, ML & Data Engineering

Joy Gao talks about how database streaming is essential to WePay's infrastructure and the many functions that database streaming serves. She provides information on how the database streaming infrastructure was created & managed so that others can leverage their work to develop their own database streaming solutions. She goes over challenges faced with streaming peer-to-peer distributed databases.

Allowing persistence or data storage to have an impact on a model. Tactical patterns, e.g. aggregate roots, simplify models and isolate them from infrastructure concerns like data storage. Starting with schemas or data modelling instead of talking with domain experts may create code based on a relational model instead of built around a domain model. On a similar subject Stefan Tilkov earlier warned about using a canonical data model within an enterprise because of the optional attributes and strange behaviour such a model will end up with.

Ignoring the language of the domain experts. Creating a ubiquitous language shared with domain experts is also a core DDD practise. This common language must be used in all discussions as well as in the code, e.g. in class and method names.

Not identifying bounded contexts. A common approach to solving a complex problem is breaking it down into smaller parts. Creating bounded contexts is breaking down a large domain into smaller ones each handling one cohesive part of the domain. It is also a key concept in microservices, something Eric Evans talked about in his keynote at this year’s DDD Exchange conference.

Using an anaemic domain model. This is common sign that a team is not doing DDD and often a symptom of a failure in the modelling process. At first an anaemic domain model often looks like a real domain model with correct names etc. but the classes are lacking almost all behaviour, instead just being containers with getters and setter for properties.

The five remaining mistakes Whittaker have recognized are:

Keeping bounded contexts despite deeper domain insights.

Assuming all logic is domain logic.

Overusing integration tests.

Treating security as part of the domain (unless working in a security domain).

Focusing on infrastructure.

A final mistake Whittaker mentions is not looking into Event Storming, a design process focusing on events, created by Alberto Brandolini. By gathering all key stakeholders in a room with unlimited modelling space and using stickers as domain events, Brandolini claims they may in hours create a very good model of a problem domain.

Community comments

Nice experience

Your message is awaiting moderation. Thank you for participating in the discussion.

A very interesting summary of the mistakes that we can make in designing our modern projects. I always thought that we have to make these mistakes in order to understand the core of DDD. We experienced a lot of anaemic models in our recent projects development. The wrong use of frameworks like Spring and of the MVC pattern have encouraged such models. I think that the most important issue in applying DDD principles remains "Ignoring the Language of the Domain Experts" as it hides other organisation problems.