> 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...
> 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...
> 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...
> 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...
> TL;DR "It's the domain modelling, stupid!" - Bill Clinton could have said if he were into software engineering. We tend to focus on technical design excellence (patterns, inversion of control, reactivity) without giving much thought to proper, maintainable domain model behind. Consequences are barely...
Well-built service API may be a game changer. In both client-server & server-server scenario, especially if you're following the latest trend of building fine-grained, loosely coupled (micro)services. I've seen several attempts, in different languages, for different domains & running on different platforms - regardless of...
