The first post in the series can be found here. Last week I've presented one aspect of complexity of the transactional part of our platform - availability (when trying to book a new appointment). And what is more important, how one modelling trick has significantly reduced coupling & simplified (and distributed) business logic. Today I'll cover another aspect of the same functionality (appointments) - pricing. And again, my goal is to show you how one Eureka moment has corrected the course of our architectural direction for the whole platform (!). Baby stepsInitially our pricing logic was trivial - each service type…
All posts in complexity
This blog post covers: the practical definition of what heuristic is, example of how imperfect heuristic may solve a problem we're not sure exists, what does it mean "everyday heuristic" (that is not really ad-hoc) and whether it's fair to call heuristic a "short-cut".It's not (& it never was) a surprise that software engineers are much better with terms, concepts & abstractions present directly in the code. I've seen several tech people kinda confused when discussion skewed towards more general problem-solving space - they didn't seem to have a good grasp on some basic terms & one of these…
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…