Eventually Inconsistent

Monday, August 4, 2014

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 You still cannot find the solution...

Everything looks good, but it seems like You can always come with another significant Scenario that will break some already created Models... You are clearly missing some concept and you need to do something different to stop spinning your wheels.

You need some...

Modeling Tips'n'Tricks

Enter the 8 Tips'n'Tricks that can help You to move on with Modeling activity. I already knew the first 7 and the last one was proposed to me by Mathias Verraes in the Twitter thread. Here You have it, you can take them and use in Your projects.

Monday, February 17, 2014

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 even some not that bad unit tests there. Woohoo, lucky
me!

I wrote first unit test, run - red of course - so I
implemented some simple solution - green - I added another test - red -
another simple solution - green - I refactored a little - green. Uncle
Bob would be proud!

Then, the time has come to write some more complex case. I
realized, that I need some additional service to be injected into mine. It was clear to me, that I needed to mock that service in test,
so I wrote

@Mock
private AdditionalService additionalService;

and it felt weird... :/

I realised, that I haven't use mocks for a long time. I just didn't have to.

Thursday, January 2, 2014

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 book at
all, but for me it was a game-changer. It is full of concrete ideas
how to master your body - loose weight, gain strength, sleep better
and so on. But the biggest thing was the idea to properly set
goals, measurements and persist in the way to achieve them. A lot
of technical or management people write about the same concepts, but
I was able to grasp them finally, thanks to Tim and this totally
different domain - human body.

"4
Hour Workweek" by Tim Ferriss - after finishing "4
Hour Body" and achieving my goals inspired by it, I decided to
dig more into Tim's work - I bought his first book, and took it on
my vacation (I love reading on a beach). Tim also writes how to
settle goals and achieve them, but a little different kind of goals.
The idea of living your life right now and not waiting for
retirement is very tempting... and maybe even possible. I will
experiment and try some more tricks from this book in the upcoming
year.

Monday, June 10, 2013

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 perspective, I can observe certain regularity. The
default modifier (usualy without any keywords) tends to be more public for younger languages. By this I mean, that default access in older languages (like C++) was ment to be private.
In Java, which is a little more modern language, when You use no access
modifying keyword, You will be able to access that code from the
package. And finally, in very young languages like Scala (and in F#, I
believe), no access modifying keyword means, that the code is public. Why is that? I do not know. I can only guess, but I personally like the Scala way.

Tuesday, April 23, 2013

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 Kraków... My current company really
liked the idea and decided to become a sponsor - so here we are:

We
are going to meet once a month - the plan is to make it always the
first Tuesday, but the very first meeting was another day and the second
will also be on different day. :) I received many wishes and
congratulations from other communities in other cities. Thanks for that!

For
the first meeting I prepared a presentation about introduction to DDD,
and then we started a discussion about business value of it. I hope
people enjoyed it. There are some photos on the event page.

The
second meeting is going to be really great. At May 6th-9th there will
be Implementing Domain-Driven Design workshops with Vaughn Vernon in
Kraków. After the last day (Thu) we will have DDD-KRK meeting and Vaughn
with Alberto Brandolini decided to give some talks to the fresh formed
community. Again, thanks for that!

So... If you are
reading this and you know something more about DDD, and you are willing
to share your thoughts, and... you know you will be in Kraków someday,
do not hesitate to contact me, and we will figure out how to find you
some audience. ;)

If you are not that familiar with DDD yet, but you are willing to dig into the topic, join our community - become a Domain-Driven Designer and participate in our meetings.

Friday, March 22, 2013

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

Tuesday, February 5, 2013

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 Event Sourcing based applications, but not only.

What we can find in Axon 2.0?

I
have been using Axon 1.3 with success, and it really helped me with the
infrastructure. In the 2.0 version, there are some improvements, which
can make this framework even more usable. The new version has added
easier API, performance improvements, out of the box scalability
support, and MongoDB-based event store implementation.