All posts in Domain Modeling

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 Too many problems in modern software solutions development are related to chasm between 'thinkers' (analysts, people with business knowledge) & 'doers' (IT specialists, mainly programmers), yet we're so used to it we treat it as something carved in stone. Why not try to apply the same bridging concept that was foundational for coining the term 'DevOps' to mix these two worlds - software crafters with sufficient understanding (& working ability of) domain analysis & technical implementation sounds almost like a mythical silver-bullet. Barely anything in life is either black or white, we're usually navigating across various shades of…

TL;DR If maintainability & extensibility of your software are among the top priorities, readibility & easy-to-grasp correspondence to functional requirements are far more important than conciseness & technical "aesthetics" (e.g. compliance with patterns) of your code. That's why to build good solutions we need much more expressive power than what any of the programming languages (of the day) offers. At some point we believed NLP will solve this issue & we'll get there with Nth GLs. This is not the case. Instead of building more generic programming languages, we need to get better with building custom…

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 Software Engineers see world in patterns, they look for common denominators, not accepting the fact that something may be an one & only instance. That's why we sometimes end up building frameworks for single problem occurrences ("we'll gonna need it in future") or try to squish accidentally similar concepts into one, common form - ignoring the fact that Domain experts don't recognize this similarity (it has no advantage in terms of domain, it doesn't constrain real-world domain development). The proper answer is (of course) to fight off instinct of pre-mature generalization & ... duplicate. It always starts…