Genetic Programming: Evolving Domain Logic a’la CQRS

This was supposed to be my contribution to first of april (Sorry guys)
But apparently people are already doing things similair to this, for real, which makes this post quite a bit less fun.

So maybe aprils fool is on me if someone implements this :-)

Most samples of genetic/evolutionary programming evolve formulas, e.g. a single mathematical formula that evolves to come up with a formula a given set of in and out parameters.
While that is interesting, it would be much more interesting and profitable if one could evolve an entire application, or at least some parts of it.

If you are into domain driven design, you have probably seen that the latest buzz is CQRS, Command Query responsibility segregation.
In short, you let your domain model raise events that can be consumed by a query/reporting store.
Thus, allowing the query and command sides to be separated.

So what does this have to evolving code?
Well, if you want to evolve code, you need some way to verify the fitness of it, how good the generated code solves your problem.
This is hard if not impossible to do for a normal application, there is no natural integration point where you can see if the application does what you expect.

However, with domain logic a’la CQRS, you have domain events, and you can easily set up a set of event sequences for a given use case.


Given that:



  CustomerId = 123
  NewName = "Foo"

Given that:



  CustomerId = 345
  NewName = "Bar"

Or preferably a more complex scenario

Given that:



  OrderId = 1
  CustomerId = 2
         ProductId = 50050
         Quantity = 10
         ProductId = 1024
         Quantity = 5
         ProductId = 50040
         Quantity = 2

This way, you can compare the expected output with the output of the generated code.
You simply have to score the events based on if they match the expected types and if they contain the correct data.

You will still have to create skeleton code for your entities and event types and describe the expected output, but the actual implementation can be generated by evolution.
That is, it will evolve the command methods that performs domain logic and changes state in your model.

In my experiment it takes on average 7-9 minutes for my POC generator to come up with C# code that solves the given problems, per command method that is.
(About 43 k generations)

IMO this is groundbreaking since the code don’t have to be tested since you already know it fills your expectations and even in complex cases the generator is usually faster than most junior developers.

A very nice benefit of evolution is that if you later get some changed requirements, some special cases, the evolver can simply continue from the current code and incrementally add the code for the new requirements.

Since the fitness factor currently doesn’t include how complex the generated code is, the output can be somewhat verbose.
Actual sample:

public void Rename(string newName)
     this.Name = (newName + "a¤").Substring(0, newName.Length - 9 + 5 + 4);

This can be solved by giving short code higher fitness than equal but more verbose code.

Thats all for now..


  1. FallenGameR says:

    Will you share the code?

  2. Niels says:

    Briljant dude! Just Briljant.


  3. This is awesome. Please do share the code.

  4. Bill Tozier says:

    Have you seen Stephanie Forrest’s Humie Award-winning paper from last year’s GECCO conference?

    Click to access gecco09.pdf

    Very similar in idea, since they were also using specification languages.

    I have to say I don’t understand what you mean by “there is no natural integration point where you can see if the application does what you expect.” Are there no mocks, stubs or other doubles in the languages you use?

Leave a Comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s