Monday, January 23, 2012

Changing the mindset - part 3 / 4 - Segregation of Responsibility

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

So, how to generate the View? First of all we have to note, that we may have many Views (screens) looking at the same data from different angles. In classic (anemic) approach we would have one Model and many, many SQL joins. But we can do something different - something more explicit.

We can create another, second Model strictly optimized for each single View. What is more - we can store those Views in some document database (NoSQL), so our reads can become really fast. I won't go into the details with their implementation, since they are fairly simple anemic-like classes created for each particular View.

So we will have the Write side (modeled in terms of Ubiquitous Language, with strong boundaries definition), and the Read side (modeled as classic anemic entities highly optimized for particular Views). Both sides will be fully separated and responsible for different user actions.

Probably you are wondering - how to feed those Views with data? If we are using single SQL database, we can just create database views and map them to View classes with some ORM. But if we use many data storages, then we have to make something different.

Monday, January 16, 2012

Changing the mindset - part 2 / 4 - Modeling the Domain

In the previous part we created Anemic Entity Match which was connected to another Anemic Entity Team, and they both were ruled by a Service MatchService. We had a bunch of getters and setters in them, which could be executed from any place that we can imagine. We didn't have any behavior in our domain objects.

As I previously said, it can be a very good approach... Of course, if you are writing your code in C or Pascal... ;) After all - doesn't those, so called, Entities look like structures or records? And please do not tell me, that getters and setters are encapsulating the state...

If we consider ourselves to be Object Oriented Programmers, than we have to start thinking differently. It is not enough to make our objects out of data. We have to teach them how to act.

Where to start?

OK, so we want to start changing the way we think to more Object Oriented, but where should we begin? If we cannot just define the data and put it into structures, where to search for the clues?

The answer is closer than we think. We use it day by day. It is our language. And more specifically - so called Ubiquitous Language.

We have to examine the words that we are using to describe Processes that takes place in Modeled Domain. We should talk to people, who have the deepest knowledge about the Domain. They are called Domain Experts and they are extremely important for the Modeler.

For the purpose of this series, let's assume that our Domain Expert gave us the deepest knowledge about the Domain in the previous post. Let's take a closer look at it.

Wednesday, January 11, 2012

Changing the mindset - part 1 / 4 - Classic approach

There are a lot of materials how to model Aggregates and Entities in Domain Driven Design. There are also a lot of materials how to manage your Event Stores, when you are applying Command Query Responsibility Segregation with Event Sourcing. And definitely there are a lot of materials how to combine those ideas together.

However, I cannot find any articles about the way that developer’s mindset (and his code) is being changed when he tries to leave the Anemic Domain approach and goes into the deep with all the concepts mentioned above.

So let’s take a closer look at it. I will provide an example and try to depict how my mindset was changed when I was adding new things to my code. I will use a very simple domain and model it in the easiest possible way, so as not to obscure the picture.

This is the first article out of four that I will write in the nearest future, so stay tuned.

One can debate if my approach to modeling the domain is the best, but for this series, I think, is good enough. ;)

The example domain

Let’s think for a moment about very simplified domain for a football match. For you guys – on the other side of the ocean – it's... ...still a football match (it's not a soccer - deal with it!). ;)

We have two teams that will play the match. We don’t know the date of the match at the moment of defining it, but we know which teams will play against each other. We can later setup the match date, but it can be done only until the match is finished. We can once finish the match with a score, but it cannot be finished before its start.

The end user wants to see the match: team names that play, match date if is set, match finish date and score if match was finished.

Monday, January 2, 2012

2011's mindfucks

Do you know what mindfuck is? Quoting the urban dictionary:
An idea or concept that shakes one's previously held beliefs or assumptions about the nature of reality.
I like this definition, but I would widen it a bit. This idea or concept doesn't have to be based on held beliefs nor assumptions. It can also broaden the horizon by introducing something completely new. However this has to really change one's perceiving of the reality. Once you see it, you will not be able to miss it again.

The 2011 has gone and it is a part of the past right now. It is a good moment to stop for a while and look backwards to see what has happened during the last twelve months.

There were two people who messed up in my head in the previous year. I met both on conferences in my home city, Kraków (Cracow).

The first person was Linda Rising. I haven't heard about her before, but she gave such a great prelection on the 33rd Degree, that I decided to dig deeper with her work and I don't regret it.

The second person was Greg Young. I knew him from many publications, videos and podcasts. I was hoping to learn something new and exciting, and I wasn't dissapointed. His workshops during JDD11 were really mindblowing.