DDD Weekly: Issue #34

Secure by Design [slides] Manning. As a developer, you need to build software in a secure way. But you can’t spend all your time focusing on security. The answer is to use good design principles, tools, and mindsets that make security an implicit result - it’s secure by design.

The secret of better UI composition [blog] Mauro Servienti. What we immediately realized is that there seems to be no canonical guide to designing UIs that retrieve and aggregate data from different sources. Sure, there are a lot of resources and discussions about Service Oriented Architectures, Domain Driven Design and the process related to correctly identifying bounded contexts; finding guidance for correctly designing your services and their interactions is no problem. But when it comes to designing an aggregator UI, there isn’t much, so it is really easy to create a UI that couples otherwise unrelated data and services.

Modelling Reactive Systems with Event Storming and Domain-Driven Design [blog] Kevin Webber. Models can be used as actionable blueprints for software development, but they can also be used simply as a tool for enhancing the flow of communication. When blueprints are used to build software, the result is code that reflects the language and structure of the business. Cross-functional teams are then able to talk and reason about the code using the same language and models as the business, ensuring future collaboration is effective and accurate.

Commander: Better Distributed Applications through CQRS and Event Sourcing [video] Bobby Calderwood. The Commander pattern imposes a clear separation of action from perception, and uses immutable values conveyed by Kafka and the Kafka Streams library to separate business logic from HTTP request processing, all while preserving the historical narrative of the entire event stream

Don’t Create Aggregate Roots [blog] Udi Dahan. The most important thing to keep in mind is that if your service layer is newing up some entity and saving it – that entity isn’t an aggregate root in that use case.

F# for fun and profit: Domain Driven Design [blog] Scot Wlaschin. In this talk, we’ll look at some of the ways you can use types as part of a domain driven design process, with some simple real world examples in F#. No jargon, no maths, and no prior F# experience necessary.

The only thing that matters [video] Szymon Kulec.

Refactoring from anemic model to DDD [blog] Zbigniew Artemiuk. We just went through migration process from anemic model to DDD and, as you can see, it is not that simple. In a bigger application it can be very difficult or maybe even impossible. Is it worth doing? Of course the answer is: it depends!

The Bad of Event Sourcing - The Pains of Wrongly Designed Aggregates [blog] Dennis Doomen. Event Sourcing is a brilliant solution for high-performance or complex business systems, but you need to be aware that this also introduces challenges most people don’t tell you about. In June, I already blogged about the things I would do differently next time. But after attending another introduction to Event Sourcing recently, I realized it is time to talk about some real experiences.

Real world events are commands [blog] Marco Perone. The most important takeaway I took reasoning about the above problem, is to always consider things in their appropriate context. The same message could be interpreted as an event in one context and as a command in another.