robocode and domain driven design

In two series of robocode posts, I've been discovering how to test drive a robot from scratch and how to do this through acceptance testing. I have yet to actually implement any substantial real code that manipulates the robot outside of any experimentations I've done a few months ago in some test libraries.

If you've been following my posts so far you may have realised that I'm actually more interested in how to solve a new problem space in a productive manner just as I would professionally. It's a chance to expand upon being agile, test driven, acceptance test focused to the solution required and a great way to try out new things and help me up my game in my process of continually being new at development.

I'm literally only a few blog posts behind the implementation so am sharing the experience as I go and one of the next things I want to introduce into my robocode implementation is some strategic elements of domain driven design.

Now I may be complicating this process  to a level far beyond what I might actually achieve with the robot code itself given that I know little about artificial intelligence and implementing winning strategies; introducing some elements of domain driven design may indeed result in over-engineering.
But that's what experimentation is all about and I'm looking forward to finding cool insights and discovering where the sweet spot is with bounded contexts and the size of the problem space at hand.

So caveat's and justifications out of the way, here's my new idea:

A robot can be quite complex and there are many things to address - decision making around where to be on the battlefield, what enemy to target, how to move, what strategy to employ. Then there's calculating distances, bearings, vectors, not to mention current gun heat, current position, energy levels. I can imagine its very involved when trying to develop a winning strategy.

As yet I know very little about these areas so I consider myself both the naive customer and the developer who has to learn about the new models the customer describes.

The solution? Break it down into contexts and simplify each area to make it more understandable, extensible and hopefully easier to identify what effects changes have to a battle.

My initial plan is to break it down into something like the diagram below - I may not stick with this in the long term, but this is my initial design idea:

ddd

The diagram above illustrates the bounded contexts I will have in my application and in between them all is the world state - this will be maintained and published via rx framework observables. Each context has a translator that will transform the world state into context specific observables each with their own dialect of the robocode ubiquitous language.

The decision context will be responsible for making decisions about where to be, what enemy to target, whether to be in close, out far away, etc. This area will deal with "enemies" and the relevant data that it will require.

The calculation context will be responsible for calculations for targeting, pathfinding and the data required for issuing commands. This area will deal with "targets" and their associated data.

The third context is the manipulation area that deals with making commands to robocode and interfacing with my robot adapter. I already have a robot engine that would be a possible candidate for this category. This area will deal with "tanks" or "robots".

Looks good to me on paper, but we'll have to see how it pans out in practice.
I already have a few misgivings that my context maps that convert to "enemies" and "targets" may actually share much of the same data and will be simply contextualising it in a different way. But that may be a good thing perhaps?

Throughout I'll not be doing any up front architectural changes, and will still be applying that YAGNI principle as I drive my implementation through context specifications. The above is just a roadmap to something I think may be useful.

I would love to receive some feedback on this so if you have been interested in my robocode series so far please share your thoughts in the comments on this blog.



1 comments:

  1. Pavel Ĺ avara August 31, 2010 at 7:39 PM

    Regarding over-design, you are probably right, but exploration is only way how to learn something and use it realistic way later. The real robot's tend to be heavily optimized for speed, because decision/problem space could be huge, but that's not in hand with readable design. Keep up the experiment, don't worry about speed. But I guess you will have to learn something about robocode to be able to specify your domain correctly.