This blog post is all about: the definition of what Model Debt is (& what isn't), how is it created (& why), how to avoid growing Model Debt, whether Model Debt does have anything in common with Technical Debt (& can one use technology to fix it).Disclaimer #1: I was considering writing this post for some time already (as another step in my "Fiber-Driven Development" observations), but the final "trigger" to finally give it a go was attending "Technical debt isn't technical" by Einar W. Høst (at DDD Europe 2019) - I think the author has made a tremendous…
All posts in Domain Driven Design
TL;DR: We're looking for a Senior System Analyst that will fit the boots of Functional Architect role for our platform. The main challenges are all about: scaling complexity, effective (& efficient) knowledge sharing, maintaining Ubiquitous Language, cultivating Domain Model that will correspond to the technical Solution Architecture. It's a chance for everyone who'd like to practice Domain-Driven Design w/o all the typical showstoppers that usually prevent it from happening.Scaling is hard. Like really, really, really hard.And I don't really mean traffic or user-base (which ain't trivial either). It's freaking hard to scale out both:domain complexity…
In this blog post you'll find out ... that design is not (should not be) dead yet, functional architecture is as important as the technical one (and should have an owner), why BABOK sucks big-time, that it's time to pimp your dusted Business Analysts, what I think about User Stories, BPMN, Enterprise Architect - and what are the most sensible replacements for these ;)Everyone has her/his obsessions, so do I. In my case the list is quite long - the leverage of modern engineering culture on software delivery, infecting everyone with day-to-day Kaizen mindset, (controlled) scaling of complexity in growing…
TL;DR Contrary to the common belief, proper conceptual decomposition of large software solutions doesn't require any particular architecture patterns in place. Being service-oriented doesn't necessarily enforce any constraints on build or deployment - it's a matter of proper, highly aware design which can't be conducted in a correct way without proper understanding of concepts like: capability, boundary, identity & role exclusiveness. Disclaimer 1: this is not a post about microservices, this one is about importance of design & proper decomposition of problems you're facing. Sometimes these're the most "obvious" topics that cause the most confusion. The concept…
TL;DR My expectations regarding software craftsmanship conferences are constantly evolving towards more focused & interactive events. Less novelties (one can learn from Internet on the very next day anyway), more warstories & workshops with seasoned practitioners. DDD Europe 2018 was such an event - dedicated to domain modeling & design in general, with majority of sessions in a form of hands-on workshop. I strongly encourage all people deeply involved in building software not only to learn more about Domain Driven Design in general, but also consider the participation in next year edition. Time for a change This year I've…
TL;DR All systems (according to systems theory - that means computer software, but also board game, biotope or set of objects that are subjects to the basic law of physics) have some underlying "rules of the game" as a foundation - these invariants are used to derive more specific scenarios / cases. Trying to model the system w/o learning these invariants leads to wrong understanding & shaky foundations. What is more - trying to reverse engineer them is a huge effort w/o guaranteed success. Some time ago, during a long discussion regarding different aspects of design…
TL;DR Domain events aren't just a fad, aimed to force asynchronous communication for the sake of being more "reactive" - this is an underappreciated modelling pattern that helps in putting a clear separation between what is the precisely defined business logic & what is the side effect, out of boundaries of current context. Lack of understanding herein may cause excessive complexity in functional areas of the greatest interest - most likely, your Core Domain ... One the goals of my recent WG.NET presentation about coupling was to emphasize that coupling is not only about loosening dependencies between…
TL;DR Getting end-users' and sponsors' feedback is crucial if you really want to build (/enhance) a good product, but it doesn't mean that you can let them "think with solutions" and mindlessly introduce suggested changes yourself. Business insights ought to be reforged into highly conscious & thoughtful updates of the model beneath the solution first - otherwise the Frankenstein of a system you'll end up with may not only be hard to understand, maintain or develop further, but also devoid of clear focus & uniqueness that made your end-users love it in the beginning. These are universal…