Eventually Inconsistent

People often treat DDD as all-or-nothing: either you do “the full thing”, or you don’t do it at all.  ¯\_(ツ)_/¯ And that’s one of the main reasons many teams never start. Because “the full thing” usually sounds like a strategic redesign, a series of workshops, a calendar full of meetings — and a request for permission that will bounce around for weeks. But DDD can be an evolution. And you can start that evolution today , with tiny steps that don’t require a revolution plan or a committee sign-off. A weekend experiment Over the weekend I created a small GitHub repo: https://github.com/pwyczes/ddd-ai-skills-applied A library of skills for AI coding agents. They’re importable rulesets that turn “help me code” into “apply this pattern, this way, with tests”. The goal is simple: Make “how we do DDD” portable across tools. Because the problem is not that the AI can’t generate code. The problem is that it will happily generate your codebase into a slightly different codebase —...

The question isn’t whether you are ready for AI. It’s whether your data is. Because some organizations have been recording their history for years — and others are still only keeping snapshots. The difference doesn’t show much today, but it soon will. Where AI meets Event Sourcing Last week I attended the AXONIQ Conference in Amsterdam, where the main theme was  “Where AI meets Event Sourcing.” It wasn’t my first time at that conference — but this time I joined literal round-table discussions . Architects, C-level leaders, and AI specialists sitting together, finally having the kind of conversations that felt overdue. Those discussions were eye-opening — not because of any new revelation about AI itself, but because it became clear what Event Sourcing has quietly been preparing us for all along. Decades of recording intent, state changes, and causality — and only now the world is catching up to why that matters. The gap is already here I’m not an AI expert. But I am a...

 Almost three weeks ago, I participated in an internal AI hackathon. The idea was simple: one day to work on any work-related project, with one constraint — rely almost entirely on AI to do the work. Code generation, design help, scaffolding, naming things, documentation, the works. Naturally, I didn’t pick something easy. I decided to refactor a core part of our system — something foundational, messy, and grown over time. You know me — if there’s domain complexity, some bounded context hairball, or a little #DDDesign chaos to untangle, I’m in. It was the first time I leaned this heavily on AI in one go. Here’s what I learned. If someone tells you AI is writing ALL their code — be skeptical. In some corners of the internet, it sounds like AI can just build entire systems from scratch. In reality? If AI is writing everything for someone, either the task is trivial, or they’re cutting corners you probably don’t want to cut. In my case, the domain was non-trivial, the logic...

💥  Krótkie ogłoszenie: Powoli pracuję nad swoim kursem online o nazwie: DDD/CQRS/ES Applied on JVM with Axon Framework Jeśli jesteś Programistą, Team Leaderem, lub Architektem i chcesz W KOŃCU wprowadzić Domain-Driven Design , Command Query Responsibility Segragation , Event Sourcing do Twojego systemu opartego o platformę JVM - zarówno legacy , jak i greenfield - to na pewno będzie to coś dla Ciebie ! Kurs będzie startował w języku polskim niebawem, a tymczasem... Dołącz już dziś do listy oczekujących, a następnie pobierz darmowy Ebook " 4 narzędzia do DDD/CQRS/ES na platformie Java " (* Plus jedno, błędnie za takie postrzegane - BONUS!) Sprawdź:  cqrsapplied.pl Do zobaczenia niebawem!

At the beginning of this year, I launched my personal website patternapplied.com (for English version patternapplied.com/en ).  I specialize in Domain-Driven Design, Command Query Responsibility Segregation, Event Sourcing on the JVM platform and with 10 years of experience in that field and the knowledge gathered over this time, I finally feel prepared and ready to share it with a broader audience . I should have done this a gazillion years ago, but hey… better late than never.  The story I’ve been doing Domain-Driven Design since 2011. During this time I was able to truly dig deep into this topic, since I was working mainly on a single product in an extremely complex and dynamic domain. Our team was responsible for delivering a new solution (next to the existing one) in the Core Domain of this product. One might say that this was a rewrite of a Legacy System, but it wasn’t. The other part of the system was still profitable. It was just doing things in a less automated and l...

It's been 3,5 years since I gave the last public talk... Way... too... long... So it has to change. And it will! I invite you to a really  innovative conference  for software architects:  SegFault Wrocław . Let's get back to the basics again. I'm going to be speaking about " Using Domain-Driven Design in legacy systems ". There will be some other experienced speakers, with a lot of knowledge gathered while working on  production systems  (not read from a book), so the event is quite unique. I'm looking forward to meeting you there! PS. I will have another announcement soon, so stay tuned...

Last week, I attended the Software Craftsmanship Kraków meetup, where we discussed "Life beyond Distributed Transactions: an Apostate’s Opinion" article by Pat Helland. Author tries to tackle the problem of almost-infinite scaling of applications. He ignores such issues like high availability on purpose and focuses only on scalability alone. That makes the essay easier to read – even for junior developer. Although the author does not say it explicitly, there are a lot of similarities between presented concepts and Aggregates from Domain-Driven Design . Pat's paper was written in 2007, so my wild guess is that he might have been familiar with Eric's book, which was published in 2004. Since there are still a lot of questions regarding Aggregate's boundaries (and technical difficulties arising around them) in DDD world, I recommend Pat's article as a complementary reading, which takes more infrastructure-oriented approach and may clarify some things.

They say, that experience is something you don't get until just after you need it. This is especially true in the field of Software Development. You may learn something from a blogpost, a book, a presentation, or even by talking to a Domain Expert, but you have to get your hands dirty in order to fully understand a concept. Enter Smart Projects 1.0 Couple of days ago, we have released  version 6.0 of XTRF platform  - a very first system that enables almost full automation of translation project management. The platform contains Smart Projects module in version 1.0, which I was developing for the last two years. In this module, we heavily used all the concepts that I was writing about on this blog for couple of years - Domain-Driven Design , Command Query Responsibility Segregation , and  Event Sourcing  of course - and it is written in  Scala .   The platform itself is not new - it was able to manage translation management projects befor...

I was sitting in front of my laptop with a bunch of paper cards scattered all around me. My desk and my windowsill were covered with printed scenarios on the one side and with handwritten sketches of couple of Models on the opposite one. On the monitor, I was browsing photos of previous Modeling sessions and, from time to time, chatting with my friend - an UX Designer. For last couple of days I was doing the Modeling of a very hard part of our Core Domain. I spoke to Domain Experts in different roles, and I was working closely with the UX Designer, who made a lot of research earlier. I run couple of Modeling sessions - both alone and in groups of 2-5 people. I just couldn't figure out a good enough solution. I was stuck. Do You know that feeling? Have You been in that moment, when you realize, that sometimes Synthesis is not that easy part of the Design process? The moment, when you feel like You are trying to push on a rope? You've done everything correctly, and yet...

tl;dr Since I embraced Domain-Driven Design, I didn't have to use any mock. When in 2011, during Java Developers Day in Kraków, Greg Young stated, that he does not use mocks, I couldn't believe him. I mean, come on! How do you test your code that is dependent on other parts of the code? I was at the very begining of my journey with Domain-Driven Design back then... Couple of days ago, I had to implement something in old part of the system. This part was developed like most systems were couple of years ago (and some are still) - with Anemic Entities and stateless, so called "Services". I didn't want to refactor this whole spaghetti around that place, so I decided to go with this anemic approach and "just be good enough". Since I am a big fan of Test-Driven Development (where it is valuable), I decided to write some test for this service that I was about to touch. Suprisingly, there was a test class for this service, and there were...

At this part of the year, many people summarize their last twelve months. So I will. This year was really busy for me. Especially the second part (hence the lack of my activity on blog). Not to extend, here are the most important things that I achieved this year, which changed my life, and will be affecting the next one for sure. 1. Books I read a lot of books this year, but there are three, that affected me the most "Implementing Domain-Driven Design" by Vaughn Vernon - a must-read for any Developer/Analyst/Architect/Whoever-builds-software - just after Eric's "the Blue Book" (or maybe in the meantime). It clearly describes what Domain-Driven Design is and how to implement it (duh, the title). It also gives a little different view at Eric's definitions - 10 years after his publication - and introduces new concepts, that community added to DDD, like Domain Events. "4 Hour Body" by Tim Ferriss - this is not technical b...

Most of current programming languages support access modifiers . I cannot imagine any contemporary language, which would not allow the developer to protect access to classes, methods, fields, or functions. Without them, we would not be able to maintain abstractions and encapsulation. In Java, there are four modifiers: public , protected , default , and private , in C# there is additonal concept of internal , which reffers to assembly, and in Scala, there are possibilities to fine-tune the scope with scoped private and scoped protected modifiers. Other languages, like C++, or F# for instance, also give us some possibility to modify access. They may vary from language to language, but the idea is the same - to protect parts of the code. (Actually, in C++ there is also a concept of friend , so that other class can get some private access to another class - hence the comment, that in C++ friends can touch each others' private parts... ;)  ) Looking from the time per...

The beautiful thing in IT world is, that people are willing to share their knowledge. That's why we write blogs, speak at conferences and form local communities. There are already couple of such communities in Kraków. Sometimes I think, that this city is really the Sillicon Valley of Poland (and maybe even of this part of Europe). There is SCKRK (Software Craftsmanship in Kraków) for software craftsmen, there are many PJUG (Polish Java User Group) meetings for Java people, KGD.NET (Kraków's Group for Developers .NET) for .NET people, Lambda Lounge for functional languages enthusiasts, Bright talks , Kraków Scala User Group , DataKRK , Hacker Space , JAR Camps and many others. If you are in Kraków, you can always check what is going on today and come to learn and share some knowledge. On the other hand, there are communities around the world, which are about Domain-Driven Design in particular. The other day I thought, that maybe we can do something similar in K...

Last week I attended, for the third time, the 33rd Degree Conference . This time I had an opportunity to give a talk by myself, so I was able to take another look at the event. I met some old friends and some new people too. I listened to inspiring talks and to couple of boring too. We also had some great talk till the late night at the first day. This was a good event. I only lack some party, like the one, that for example, usually during Java Developers Day takes place. As the year ago , I decided to give some subjective marks for each presentation. And by subjective I mean, that notes were taken only be me, according to my perception, my knowledge and my sense only. There was nothing personal in them, so please treat them appropriately. :)

In the CQRS world people don't like frameworks. People like to concentrate on the domain and on customer's problems. This is really great, but in the end you have to write some code to handle command, load aggregate, or save and dispatch events. Long story short, you need an infrastructure. Although it is not that hard, to write this code, it is still the code that has to be written, tested, and maintained. There can also be some tricky places - especially if you have to distribute the system, or implement sagas. So, why bother with that, if we can take someting of the shelf, and just use it in our system? If the framework does his job, is flexible and does not deny things that we need, I would recommend to use it. It allows us to concentrate on the business problem. Of course, if you use the right tool for the job. I mention that, because there was a major release of Axon Framework 2.0 couple of days ago. This is a Java open-source framework for CQRS and/or E...

Been a long time since I last blogged. There were many things happening, which were pulling me away from writing. One of those things was an opportunity to share my thoughts with a wider group in public. Recently I gave two talks - one in my company, and a second during JavaCamp #11 . The second one was filmed and you can watch it below (in polish). The topic was "Changing the mindset - more object-oriented view at the business domain modeling" and it was based on my series of previous blog posts (links below). I briefly introduced audience into Domain-Driven Design, Command Query Responsibility Segregation and Event Sourcing concepts. The main thing in my presentation however, was to show how developer's mindset is changing when meets those contemporary techniques. I wanted to emphasize what questions she starts to ask and what things are becoming more important while she goes step by step over this "rope bridge". Both speeches were well recieved, I th...

For a very long time I was told that tests should not influence the production code. By this I mean, that we should not change our design only in order to be able to test it. That was quite OK for me, since - you know - test are only tests - the production code is what matters and what drives the design. Tests should just shut up and follow. Right? Lastly I am flipping the bit and diving into TDD and I must say - this is quite an adventure. At the beginning I was like a babe in the woods. It was not easy to start. Everything was harder - writing code, designing, thinking... I had to firstly write a test, and then the code - everything was upside down - I didn't even have the code to test. Damn! I started to think about basics again, and that... was really refreshing! The Example One day I was given a task to figure out changes in history lines of some objects and update the meta-data for each line accordingly - with ids of objects that were changed. For the simp...

We like Design Patterns. They make complicated things simpler. Our brains are designed to tackle complexity with them. It is easier to describe something with words "it's like that one thing that you know, but with some differences" than describing it completely from scratch. All frameworks that we use are full of Patterns and we understand them very well. Decorator here... Chain of responsibility there... Oh, and some old, nasty, huge and extremely overloaded Singleton over there - yup, we use it too... Piece of cake. This is our (developers) well known Domain. We are Domain Experts on that territory and we feel confident there. The reality But guess what - this is not the Domain that we are dealing with on daily basis (unless we are working on frameworks of course :P ). Our Domain, which we are struggling with, is about the business that runs our company. We don't need those mentioned Decorators and stuff. At a glance, it looks like we can ju...

It's been a month and a half since I wrote the last blog post. This time it was not because I am lazy (although in general I am), but quite the opposite. I was very busy with launching my startup application written after hours at home with my brothers. For the couple of last weeks, there was the Euro 2012 Cup in Poland and Ukraine, and everybody around me was crazy about the football those days. On the other side, couple of months ago I started to practice Domain Driven Design with Command Query Responsibility Segregation with Event Sourcing . I combined those two and launched my startup as a Facebook application written in this style: " Typer " (at this moment only in Polish). What were my goals? From the personal perspective , I wanted to give people some opportunity to have fun - to type scores in their own groups, compete with each other and find out who is the best football specialist. From the business perspective , I wanted only to generate s...

I want to emphasize at the outset, that I am not an expert in graphics.  I just have some basic knowledge, but based on that I was able to coin this parallel. I assume, that you have some basic knowledge about Event Sourcing and CQRS , but if you don't please refer to this definition or watch Greg Young's mindblowing 6,5h long classes (if you already do have some knowledge, watch this video anyway - it is worth your time). I also assume that you have some very basic knowledge about Vector Graphics and Raster Graphics . What is an Event? Stop for a moment and think. Probably you will come up with an answer, that an Event is an Aggregate's state change which occurred. And this is a very good answer indeed. Guess what. Vectors can depict the state change too! So Events may be treated as Vectors, right? Below I will write down some similarities that Event Sourcing has with Vector Graphics, and 3rd Normal Form databases have with Raster Graphics. 1. Scali...