Eventually Inconsistent

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...

I think that most of us are familiar with the term " Convention over configuration ", but just to remember (from wikipedia): The phrase essentially means a developer only needs to specify unconventional aspects of the application. For example, if there's a class Sale in the model, the corresponding table in the database is called “sales” by default. It is only if one deviates from this convention, such as calling the table “products_sold”, that one needs to write code regarding these names. When the convention implemented by the tool you are using matches your desired behavior, you enjoy the benefits without having to write configuration files. When your desired behavior deviates from the implemented convention, then you configure your desired behavior. For example, the maven project structure uses convention - where our source files, test source files and resources should be placed in order to be compiled, tested and packaged automatically. We save a lot o...

One of the best conferences for Java masters in Poland has ended. The 33rd Degree . I've been on the previous one and I really enjoyed it. Totally 5/5. However, this year was a little different. I also liked it, but I think it could be better. Some speakers were inspiring, some were boring. ;) And some were talking about things that I already know... Maybe I should read less? ;) So to shortly sum it up - there was not a single mindfuck during this edition. And that's a pity. I decided to give subjective marks for each presentation that I attended and here they are:

Let's imagine a situation. You are a person that has some time and wants to learn something new. You have two options briefly presented: Domain Driven Design on the one hand and Command Query Responsibility Segregation on the other. What would you choose? (Before you start reading below, understand that I compare those two concepts only theoretically and I am not taking under consideration how they interact with each other) For me it would be pretty straightforward - DDD of course. Why? I will explain below. However for most people that I have met I see the opposite... I still cannot fully understand why, but let's try to investigate a little... What Google says?  I made some quick investigation in the Google Trends. I typed "cqrs" and "domain driven design". When I typed "ddd" or "command query responsibility segregation" the results were unreliable. We can see that DDD was first and at the very beginning it was m...

This is the last article out of the series about changing the mindset. At the beginning we took the Classic approach , and then we introduced three important concepts (in the order): Domain Driven Design ( Modeling the Domain ) Command Query Responsibility Segregation ( Segregation of Responsibility ) Event Sourcing ( Segregation of Responsibility ) In the previous part we separated our Read and Write Models. We also applied Event Sourcing as a persistence mechanism for Aggregates. We also equipped the Aggregate with behavioral methods only, and got rid of getters. Everything looks really nice. The Model is clean, verbose, and everything is explicit (as for such a small example). We have one data store for the Write side, and we don’t have to care about distributed transactions. We can even easily provide historical data. However, if you paste the last piece of code from the previous part to your IDE, you will see that there are many warnings on the fields – "never...

In the previous part we created quite verbose object oriented Model of our Domain. The Domain itself is extremely simple, but try to imagine your Model, which you are working on day by day, that would be so explicit. Wouldn't be easier to understand it? Whatever you can do on an object, you do it directly through methods, which names and arguments, comes strictly from the Domain Language. And even those objects' names come from this Language too. Well, this is just OOP done right, isn't it? There is actually one issue with that approach. We want to show some of the data to the user. And if so, then we have to expose internals. So in addition to our well-crafted, encapsulating behavior methods, we have leaky getters... Clean the model Let's do something that may look a little strange for the first time. Remove those getters. For a moment don't think about the View. Doesn't the Model look pure and clean without them? It has only behavior as a bo...