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 Domain Driven Design
Few months ago I've published a short article about what is a Model Debt & why it matters. Today I'd like to provide you with two nice, crispy examples that illustrate the idea. Both are coming from the Domain I currently work on with my teams - booking appointments in Beauty & Wellness industry. Booking an appointment initially was very straightforward. Apart from knowing what (particular service) you were booking & whom (which stylist) you were booking, the only challenge was to make sure that no-one has booked the same time-slot (of a given stylist). We've achieved it in the…
This blog post is all about: the common part of "Shallow DDD" & "Aesthetic Clean Code", what really is Business Logic (& why you may be wrong about it ...), what part of BL is really within your "algorithmic" (imperative) code and where you should really apply your focus to if you want to improve Business Logic.Disclaimer: we're using code to create all sorts of applications, following radically different paradigms - it's not possible to find a common denominator for all kinds of apps. This blog post focuses on a typical, web, interactive, user-facing OLTP-sort-of applications (because of how popular…
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…
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…