IDDDtour 2013 Belgium - an immersive experience

by Tom 1. May 2013 00:36

Introduction: what & how?

"Implementing Domain Driven Design" is a book written by Vaughn Vernon, and you can consider it a practical guide to the blue book - a lot of people consider the blue book to be used as a reference, but it takes some persistence to read it -. Vaughn tried to solve exactly that problem with his book...

A little while ago, Vaughn Vernon was tweeting about how had given a free course about his book "Implementing domain driven design" while visiting Bogota, Columbia. This course was given for free to help start-ups there.

In the next few hours after this tweet, an idea emerged on twitter about a concept called the IDDDtour, where Vaughn would be teaching his book to larger classes and doing a tour through Europe, but at a fraction of the cost. As I am somebody who is more of a head first kind of guy, I decided to take ownership and figure out a way to make this a real thing...

More...

Fallacies of the tech recruitment process

by Tom 16. November 2012 08:49

Note: I would like to thank @gbarrs for reviewing my blog post almost instantly, and also the offer of @GraemeF, @MarkRendle, @swaggerdmangene and @moldyseaswimmer to be a reviewer. Without them, there would be a lot more Dunglish in this post...

Why I like my job.

I have been hooked into computers ever since I wrote my first few lines of Basic on my mothers' brand new TRS-80 Model 3 with 64Kb of ram and 2 - yes 2 !!! - diskdrives of a whopping 178Kb. (Actually, I did not write the code, but I copied it character by character from a textbook that might have looked like this, but in my defense, I was about 7 years old).

The first program probably looked like this:

10 PRINT "HI, WHAT IS YOUR NAME?"

20 INPUT N$

30 PRINT "HELLO, ",N$

Exciting, is it not? In the five years that followed, I learned almost every in and out of this machine, where to peek and poke in memory, how to set pixels on the screen (monochrome, 128x48 resolution, imagine that), which ASCII codes to send to my dot matrix printer to switch control modes, ...

When I was about twelve years old, I had written a drawing application, complete with circles, boxes, Bresenham lines, and even the possibility to print the graphics on the (very noisy) dot matrix printer (remember those printers which had to print on chained paper?).

More...

Erlang 101: an attempt to implement CQRS

by Tom 5. October 2012 04:03

Introduction

As you might have noticed in one of my previous posts, I am currently focussing on Erlang, because I assume that this platform might be the most efficient way to handle umphteen connections over the web for now (but that is the subject for another post).

After running my first experiments and getting everything up and running on Windows, I finally decided to stop fighting usage of windows combined with Erlang so I installed myself a virtualbox with Lubuntu LXDE (please note that you have to set the available memory on the virtual appliance to 512MB, or the installation will crash).

Before I start implementing what might be my next startup, I tried implementing one of the things that I consider to be my personal kata (I made numerous attempts in .Net): a CQRS implementation of a simple stock system.

Disclaimer: I am a complete newb in Erlang, so I presume I am still miles away from a more elegant implementation.

More...

Project #Startup10: Working title - BIG

by Tom 9. August 2012 11:47

note: The source for this project is on Github; the following text is a copy of the file Readme.md.

Project #Startup10 - Startup #3 : Project Big

This is one of the projects of a bigger one: Project #StartUp10: Creating 10 Startups in one year.

The idea of project #3 was to create a platform to implement some really quick solutions for small problems. I would come to a customer, anayze the small issue in about 2-4 hours; implement it in the same timeframe, and by the end of the day the customer should have a working solution.

The solution implementation would have been lowcost, but there would be a small recurring fixed amount/month/user fee.

Architecture

It is currently still completely running clientside, and is just a very simple concept

  • you have assets or code with a mime-type
  • interaction between code happens using events

The idea was to distribute these events to other clients and the server using signalr or something similar

Example

Here is a simple example to prove the concept

code://Domain.Alerter - text/x-coffeescript

class Alerter

  alertcount: 0

  alert: (message) ->
    if (@alertcount < 5)
      emit 'alerted'
        message: message

  handle 'alerted', (e) ->
    @alertcount+=1

code://Denormalizer.Invoice - text/x-coffeescript

handle 'alerted', (e) ->
  loader.modifyTable 'table://invoice/123', ->
    @A5 += 1
    @B5 = e.message
  alert (e.message)

code://Example - text/x-coffeescript

code://Domain.Alerter
code://Denormalizer.Invoice

SUT = new Alerter()
for i in [1..10]
  SUT.alert "Woohoo #{i}"

report "<h1>Done</h1>"

How does it work ?

First you need to add the code resources mentioned on top as well as a "Data resource" named "invoice/123"

Then you press "Run" on the example, et voila, everything should work/compile, and you should see the updates in the excel-like grid in green, and a "report" saying "Done"

Demo

As usual, you can find the demo over at Appharbor: here.

Why are you not persueing with this project/Startup ?

Every single person I mention this to does not "get it", so I consider this not the way to go... For now at least. Maybe I will continue with this later on, but for now, I consider this a failure.

CIAO

 

Bookmark and Share

Epilogue: One night in Paris - #CQRS, beers and life in general

by Tom 13. July 2012 09:26

Introduction

When I told people I was going to drive to Paris (350KM, a 3 hour drive, traffic jams not included) to have a discussion with a few persons I know from the internet, most of my friends were questioning my sanity.

They know that I am not really following the path most people follow in life and career, but apparently to a lot of people really considered this to be one of my more exotic quircks, hence this blog post explaining my ideas.

Cost & Time

Why do you want to go this far to have a chat of a few hours with some people you have never seen before to talk about your work, and all in your free time. Have you considered the cost of doing this? Could you not find a better way to spend your money and time (on your startups for example) ?

Let's see:

  • Time: +/- 8 hours of driving; we probably talked about 4 to 6 hours..., and I had to spend the night in Paris - basically a 24h time-frame
  • Cost: 120€ for the hotel room, and add about the same amount for expenses/gas/"payage" etc
  • Unknowns: true: I had never seen them before in real life (even though I did read a lot of their articles and tweets, so I did have a general idea who to expect).
Hmmz, that seems like a lot, or not?

Project YakShayQRS : another CQRS evolution

by Tom 19. March 2012 14:50

Introduction

TL;DR: I managed to minimize the CQRS overhead even further.

Over the years, I have been trying to minimize CQRS in several iterations, even releasing a framework and a lib in doing so. Yet, I have still not been satisfied by the approach I reached. This time I once again am pretty satisfied with the way things turned out, and they actually seem to require even way less overhead...


How it works

The concept is quite simple: I use a generic message class to implement messaging. Next to this I use the virtual keyword:

 

  • A class can contain virtual properties; these properties define the unique key of the instance. (f.e. an "Account" class has a "protected virtual string AccountId {get;set;}").
  • When invoking a message on a class type, an instance is loaded where the unique key is loaded based on the match between the message parameters and the classes' virtual properties. A message only gets invoked if it contains all the virtual properties from the class.
  • In order to alter state, one should use a virtual method.
  • One can only send messages targetting non-virtual methods to a class instance.
  • Non-virtual methods should never alter state, but instead call a virtual method that alters the state...
  • When rebuilding state based on past events, only the messages targetting the virtual methods are invoked to rebuild the state; no messages are emitted.
The advantage: all the wiring is convention-based; and once you get it it is quite easy: altering state should only happen through virtual methods, but these virtual methods should never contain any logic and just alter state or do nothing. The intercepted call to the virtual method gets emitted and gets processed by any non-virtual methods in other classes (if the message matches the classes' key).

Presentation: CQRS 101 - All your BASE belong to us - on march 6th for visug.be

by Tom 22. February 2012 06:01

I am presenting for Visug on the 6th of march; it is a session about CQRS; here is the abstract:


CQRS 101 - All Your BASE Belong To Us

CQRS is a relatively new approach to software development in complex, distributed and/or asynchronous problem domains.

In the first part of this session, you will get a brief but pragmatic overview on the what, why and when using some examples. You will see how CQRS leverages BASE in CAP-theorem, and how this translates to the cloud. We will also touch some of the major advantages and disadvantages of this pattern, including applicability to TDD/BDD and NoSQL-like environments.

In the second part we will get our hands dirty by implementing some sample domain behavior, using one of the many possible CQRS approaches. You will see how CQRS really separates business logic from infrastructure, and that infrastructure in itself is practically interchangeable. Next to this you will also see how the combination with eventsourcing allows you to completely remodel historic data without a lot of effort.

Before the Q&A starts we will end with a small overview of the session, together with some practical tips on how you might use this approach today.


Unfortunately the session is sold out, but hey, if it is a success, I am confident more of them will follow...

 

Update

The presentation is over; 45 people; a great crowd and lots of interaction....

While I covered quite a lot of ground, I think the biggest remark was to show more concrete examples; you can find the slides here

I published the (cleaned up and bugfixed) example sourcecode on github.

Feedback/tips/Remarks ? Please let me know your opinions in the comments, so I can improve it!

 

Bookmark and Share

CQRS for the lazy -ss

by Tom 15. January 2012 05:36

Introduction

In one of my numerous attempts to create a neat approach to CQRS, this is yet another attempt to remove all the protocol that CQRS requires. I love bootstrapping new projects and experimenting with new approaches, and this is another step that improves efficiency. It is a natural evolution to one of my other CQRS playgrounds: Scritchy.

The conventional CQRS approach requires you to write command - and event classes, to wire up your commands and event handlers to the relevant AR's, saga's and viewmodel builders.
I removed some of the clutter in that process with Scritchy. Scritchy uses conventions to wire up the commands and events to the relevant components. This makes CQRS a lot less verbose while still offers the same advantages.

Scritchy v2 ?

While this is a good attempt, it still requires you to write the dreaded event - and command classes. Having pushed some best practices/usages/libs to some enterprise teams in the past, I noticed the following: any change that adds extra steps/work to the process makes acceptance harder by devs, as most people are usually trapped in a certain approach, and they do not see an advantage in having to write more code to do the same thing. If they do not need to write all the "protocol"/extra classes, you have removed yet another step that might slow down acceptance of the practice.

 

The new approach I am about to tell you about in this blog post completely hides the messages from the dev, i.e. the dev can just use a conventional method call, and messages are created underneath.

 

Disclaimer

This is a possible approach to the problem, but I tend to think that the majority of the CQRS evangelists and practitioners value explicitness over pragmatism. I love the explicitness and clarity of their examples and implementations, but in the real world most people start to think: "Wow, that is a lot of code to simply add an item to the stock; are they nuts ?".

Having experienced the fallacy of the explicitness in a startup attempt, my brain got tickled to find fast and neat approaches to a pretty established conventional path. I think this one is pretty close.

The full source is available over at GitHub, and the demo app can be seen/tested over at appharbor.

Example

So without further ado, here I will show you ALL THE CODE required to implement a complete CQRS app:

More...

2010 - 2011: A retrospective

by Tom 27. December 2011 04:25

One of my main motivators, my youngest son Matisse #PrideAndJoy


Introduction

I like the concept of retrospectives; it makes you self-reflect and think about the paths you followed and want to follow in the future. As it has been 2 years ago since my latest retrospective, I think doing a post on it right now might be a good idea.

More...

Continuous thinking: CQRS explained to a 10-year old

by Tom 28. November 2011 03:20

Introduction

The concept behind CQRS is neat: detach your domain implementation completely from your representation requirements. I even wrote a framework for it as a learning tool, so somebody without any prior experience should be able to boot a CQRS app in a few minutes.

The main idea behind this framework is providing developers new to CQRS an operating room where they can compose their own little CQRS Frankenstein app.

The whole framework is constructed in a way that it forces you to make your domain implementation completely persistence ignorant, respecting typical AR/transactional boundaries.

Scritchy is not "the framework to write CQRS apps"; Scritchy is a framework that tries to provide you a learning platform where you can start grasping the basic principles, advantages and disadvantages in using CQRS.

Once you understand the basic principles behind the CQRS setup, and why everything is setup the way it is, I would advise anybody to gradually replace parts of the framework and just opt for whatever approach you like, using proper message busses, pub/sub/... 

If you write your app following the conventions Scritchy dictates, the only thing you need to change to remove the Scritchy dependency is the base object your Aggregate Root inherits from; that is the only dependency that is ever necessary in you app implementation. This was by design,to make future migrations as easy as possible.

I wrote this framework to enable a dev new to CQRS to get his app up and running in a few minutes... But apparently that is not enough....

More...

About Tom

     Tom Janssens op LinkedIn    Tom Janssens op twitter   Core bvba RSS

I build software and help organisations to get better at building software.

If you would like to know more or meet up, just give me a call at
+32 478 336 376.

More info about Tom and his company...

Tom's resume


Calendar

<<  April 2014  >>
MoTuWeThFrSaSu
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

View posts in large calendar