Experimenting with Remote Wardley Mapping [video] Nick Tune. Wardley Mapping is a strategic tool for anticipating how domains will evolve over time. In this session, we’ll learn the basic theory behind Wardley Maps and then jump into hands-on exercises.
Designing a Domain Model to enforce No Duplicate Names [github] Steve Smith. You have some entity in your domain model. This entity has a name property. You need to ensure that this name is unique within your application. How do you solve this problem? This repository shows 11 different ways to do it in a DDD application where the goal is to keep this business logic/rule in the domain model.
The danger of async/await and .Result in one picture [blog] Konrad Kokosa. Sync over async in .NET is always bad and there is no better advice than just to avoid it. What does “Sync over async” mean exactly? It happens if you synchronously wait on an asynchronous operation result with the help of .Result, .Wait or similar. Why is it bad? First of all, it blocks (wastes) one thread to wait on a result – which may lead to threads starvation. But even worse, it may deadlock your operation and (sometimes) the whole application.
Data flows between Bounded Contexts, behavior is way more context specific. Drawing service boundaries around data will lead to distributed coupling. Not exactly my favorite place. [tweet] Alberto Brandolini.
“Full Resource Utilisation” [blog] Trond Hjorteland. There is a reason why the title is put in quotes: The idea of 100% resource utilisation is not only a fallacy and hence impossible, it is actively harming our performance, the output of our hard work, and the quality of what we put in front of our customers. And the crazy thing is that there is a one simple thing that can fix this: Do less!
Distributed Domain-Driven Design Day [video playlist] [Virtual Domain-Driven Design] Virtual Domain-Driven Design.
Conway’s Law, DDD, and Microservices [blog] Steve Smith. Conway’s Law states that “any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” This has significant impacts on how software is built, especially if microservices and/or Domain-Driven Design are adopted.
Overselling Event Sourcing [blog] Alexey Zimarev. This post is a part of the Myth Busting series, mainly about all the misconceptions about Event Sourcing here and there. Each post either addresses a common misconception or a particular article on a public resource. I will address specific issues with a given article. You might want to read the original article to get the context. Original article: Stop overselling Event Sourcing as the silver bullet to microservice architectures by Oskar uit de Bos.
Architecture Jams: a Collaborative Way of Designing Software [blog] Gergely Orosz. It’s a good idea to facilitate an architecture jam early on in the design process, instead of letting it play out organically, over a longer period of time. Doing so will mean more immediate feedback, a lot more people invested in the idea and blind spots of the approach caught earlier.
On Coding, Ego and Attention [blog] Jose Browne. My thoughts on coding, ego and attention. How I learned to get out of my own way by learning about this link between ego and attention.
Introduction to DDD Lite: When microservices in Go are not enough [blog] Robert Laszczak. Fortunately, a big part of the knowledge that we are sharing is universal and can be applied to multiple technologies, not only Go. You can treat these learnings as an investment in your career and mental health in the long term. There is nothing better than solving the right problems without fighting with the unmaintainable code!
I wrote Task Manager and I just remembered something… [blog] Dave Plummer. Some tips about using Task Manager from the author of Task Manager.
Learn to never be wrong. [blog] Will Larson. Most folks have worked with someone who thinks they’re never wrong. In each discussion, they lean in, broaden their shoulders and breach their way into the role of the decider. They’ll continue debating until their perspective wins the day or time runs out. They are often right, but right in a way that sucks the oxygen out of the room. As their tenure at a company increases, they may fancy that they’ve become very persuasive, but frequently it’s a form of persuasion characterized by the resignation of their peers.
Computer Architecture Takeaways [blog] Patrick Louis. Computer architecture can be considered a boring topic, one that is studied during CS education, then put aside, and leaves place to the shiny new toys that capture the attention. I’ve recently revisited it, and I’d like to summarize some takeaways.