My perspective on the coding versus modeling balance

Root Cause Analysis stencil uploaded on Graffletopia Stencil

There are few OmniGraffle stencils which I use frequently during my consulting gigs, especially while gathering information for a change initiative, and in presentations also. One of my favorites is the one I just uploaded to Graffletopia for sharing.

Notation info

• Observable Facts are ellipses (or bubbles). 
• When using a tool for drawing like OmniGraffle, I take advantage of colors to display perceived severity. White is neutral, from yellow to red is bad. Black is disaster.
• Border thickness maps to our perception of our ability to affect/change a phenomenon. A fact with no border is under our control, a fact with a thick border is something we cannot influence easily. A company policy which is generating an undesirable effect might be mapped like a constrained fact (but later, you might be in the position to influence it).
• Unknown Areas are represented as clouds. There's something important there which we don't know yet.
• Question marks are part of the stencil as well. I never know everything, but mapping the things that I don't know is often a good idea.
• Since my primary use is to collect information for change at a system level, local solutions are part of the notation also.
• Direct dependencies are represented by arrows. 
• Dotted line arrows represent indirect dependencies. I'm less strict than some other more precise notation, I use the same dotted line for not-so-clearly-related facts and for relationships with delay. It's less precise, but at sketching time I probably don't have enough information to make a clear distinction anyway.

Some guidance

I have to admit I am driven by instinct more than a real formal process. However in drawing the map I have influences from Peter Senge ("The Fifth Discipline"), Craig Larman ("Scaling Lean & Agile Development" and from Eliyahu Goldratt (who described the Reality Tree in "It's not Luck!").

Collecting Data

I start collecting sparse data, from my observation. If I can draw direct links, I add them. If a fact has no clear explanation, I add a cloud or a question mark. Same goes of the causal effect link is no sufficient to imply the consequence. The fact that it's raining doesn't necessarily imply that I'll get wet. But if my car is broken, and I have no umbrella, and I have to go shopping for food, that's another story.

I don't need that much precision on the constraints. I like to capture the mood. If the team says there's nothing that it can be done about a policy, I'll draw it as a constrained fact. But I'll challenge that assumption later when it comes to use the drawing for collaborative problem solving,

Please feel free to share your comments. Hope you'll find it useful!

Setting up a DDD sample app

The guy who started it all is called Emanuele Del Bono. He’s a friend, a nice guy and a respected colleague. He participated in the first Domain-Driven Design class of my company, and also did a fantastic job in finding a suitable place for the class. He is also one of the guys that animated a discussion on the DDD-IT mailing list that urged me to write this posts, some time ago. So I should have been warned about the danger behind his simple request.
Some weeks ago, he complained about the lack of code example in the DDD-IT mailing list, and challenged the list to see if anybody dared to post the code of some aggregate. Innocent and legitimate request, ...or so it seemed. However, since he used the word “courage”, the one that kids use among themselves to do things they will regret, I accepted the challenge and started working on some code that could be shared, and found useful by the list.

Why should I regret it?

As I said, the request is both legitimate and innocent. What could be the drawbacks. I can point out two.

Time: I like to do things well, and sometimes I tend to get lost in meaningless details. So, for me, doing things right will take time. Given how busy I am, there’s a clear and present danger of never finishing the stuff.

Questions: there are many things that I don’t want to talk about when talking about Domain-Driven Design. Frameworks are one of these. I use some of them, but I can’t really say I love them. However, I don’t like questions like “how do you do this with Spring and Hibernate?” because you can probably do it in a smarter way that I can figure out. I think one of the values of DDD is to provide a conceptual background where these type of problems, decrease their importance to the point of being mere implementation details (even though they can make your time a hell if they don’t work exactly as expected). So my worry is to get too many questions focusing on the wrong side without really clarifying doubts on the part that matters most.

Choosing a domain

I definitely need something different from Cargos. Since I know the training domain a little, and used it also in the recent DDD school camp, I decided to choose this domain. However, as will be clearer later, we’ll need precision in defining what this is really about. Simply knowing how things work in the training domain won’t be enough.

Choosing a programming language

Since colleagues were eager for code, the first thing to do was choosing a programming language to actually show some code. The obvious choice was to choose my favorite language and get along with that. Problem number one: I don’t have a favorite language. Problem number two: there are too many things in the code that could divert both writer and readers attention from the actual scope of the task.

Java: this has been my first choice, a little conservative I have to admit. However, it’s bee a while since I wrote some java code, and I stopped following Java trends after Oracle’s takeover. Last but not least, all of my local configuration needed an update.

Groovy: a lot more pleasant to work with than Java, but to make it really pleasant I had to deconstruct Grails a little, in ways that might look obscure to most readers, carefully selecting only some of the available features. Good topics for a blog post, but not for this app.

C#: though I’ve been recently playing with the platform, and I appreciated some features, I still don’t feel like it’s mine. Still too hard for me to distinguish good and bad stuff.

Ruby: I am relatively new to the language, and probably missing some key tips on the technology stack and on the programming style (“You still think like a Java guy” Paolo Perrotta once said, I hope I improved a little since then…).

Given this starting point, I started with Java. I thought I could set up quickly a skeleton architecture with Spring, like the ones I was used to work with.

So I opened up the IDE and started coding.

Wrong choice.

After setting up an Aggregate an some satellite Services that did their dirty job, or faked it with a mock implementation, I finally realized that I was getting all wrong and was underestimating the task of writing a sample application. What was my problem?

Ambiguity.

The model I was building looked perfectly sound from a “modeling” perspective, but I was getting uncomfortable in the multiple roles of developer, analyst, and domain expert or product owner. Moreover, the “let’s show some code quickly” approach that I started with, didn’t really work. To define exactly what my aggregates were supposed to do, I needed a lot more precision, since a little business tweak in the underlying domain would have driven me in divergent modeling choices. I needed consistency and unity of vision in my domain, before I could implement it in my model.

Well, that was no surprise. That’s exactly what DDD is for. And a common, simplified development cycle is:

1. gather some information from the domain expert about features A, B and C;
2. quickly implement it as a domain model, using DDD patterns;
3. spot contradictions in the current understanding of the domain, that emerge from the model;
4. refine the model, asking to the domain expert what he precisely meant when he talked about features A, B, and C.

The only weird thing is that all the roles are in my head now. And to keep my sanity and stop swinging from one interpretation to another one of the same corner of the domain, I need to be a little more structured, and define exactly what I want from myself.

Providing a little structure

I want to model my aggregates around a problem, and I want this to be precisely defined. So, despite this being just an example, or maybe exactly for this reason, I can’t go for shortcuts. Let’s start with a user story and see where it lead us. 



My first problem was to find a good name for my role. I mean, my company is rather small, so there’s not much of a clean role separation. I could have put something like “as Me” and was probably going to be more correct, even if less portable.

However, that’s defining the starting point, and the scope for the first iteration. But it’s not precise enough. Let’s nail it down with an acceptance test.

Scenario: Publishing a new training
Given a Catalog
And a Training gourmet coding not yet published
When I publish Training gourmet coding on Catalog
Then Training gourmet coding is available on Catalog

And try to make it work. Of course this means setting up Cucumber in the development environment, something I thought it wasn’t strictly necessary, but I realized I am getting addicted to.

By the way, despite my previous experiences with Cucumber and Java, and the precious guidance by the secret ninjas cucumber scrolls, setting up again Cuke4Duke in my project didn’t work that smoothly. Looks like Maven got in the way. Again.

No, please. Not that again.

In a second, Maven destroyed my pleasure. And made me think that, even though I am still a rookie on Ruby, every second spent on solving problems on Ruby is a second spent learning, while the time spent on Java is probably wasted. So, after just a few minutes, I already dropped my platform and started again with Ruby, instead of Java. But this sample app is a sandbox, for learning and experimenting. Needs to be fun.

Modeling question number one

Do I really need a catalog? When thinking about managing trainings, a Catalog is the abstraction that naturally comes to mind. However when I started thinking about what I really wanted to do with this application, I couldn’t find any behavior for the catalog within the boundaries of my application. I said “boundaries” which means that I need to define scope more precisely. A little context map will do the job.

The ultra-basic context map, with my application and an Anti-Corruption Layer separating it from the external website model

 The main idea, for now, is to manage the trainings locally and trigger a publishing action on an external website. I have no idea about how to do that, but I need to make it clear that I am not directly working on the catalog that is visible to a potential customer. I have an external website for that. Maybe some hosting service exposing APIs would do the job. But I don’t want to know that. Right now I just need to know that I won’t publish directly on that. I’ll hide the details behind some domain service and hide all the little dirty things needed to complete the job behind the curtain of a neat interface. More likely, I’ll pretend to do that, and shamelessly fake everything, but behind the same interface.

Ruby, the architecture and me

I hereby state loud and clear my ignorance about the architectural patterns in Ruby. I don’t know much about it, so whenever you see something that doesn’t quite fit the picture or that seems awkward, feel free to comment and correct me. The only thing I am almost sure about is that I don’t want to use Rails. Can’t say it won’t fit in the picture (I am not looking for a 100% DDD application, and I can figure out portions of the application that could be implemented according to that paradigm) but definitely Active Record is not what I want to start with, and definitely I don’t want a full framework stack. I want to add things little by little.

Persistence framework

After exploring a little, I’ve chosen Sequel. A lightweight persistence framework that can be used at two different levels of abstraction. I started with the very low level approach, so my repositories now look a little vintage. :-)

Also DataMapper looked interesting. I’ll probably give it a try when trying to make the architecture a little more agnostic about persistence frameworks.

The trickiest part so far has been separating persistence instructions from transaction management. In a typical DDD architecture, transaction management is an application layer concern, but this seems to be at odd with most of the examples regarding ORMs and persistence frameworks in general.

What I like so far

I really like the Ruby testing stack. Cucumber and Rspec are incredibly well supported by RubyMine, and coding is a pleasure in this area. Getting to all green is always a pleasure.

What I don’t like so far

Of course the database had his revenge after that presentation. SQLite rebelled and I wanted to test the app also with some real DMBS, but installing MySQL has been a little pain (well, the actual installation run smoothly ...it just didn’t work with my Ruby version). I had to switch to a different Ruby version and to reinstall it before having it work with my stack.

There are also a few things that don’t feel right on the architecture. I missed some of the things Spring was doing behind the scenes, and that used to be my default paradigm so there is a high possibility that the whole stuff looks like a Spring based Java application in Ruby dress. Some patterns which are relevant in Java and C# (like Application Facade and Repository) probably have a more elegant alternative implementation in Ruby, and there are some Singletons around (forgive me) which are basically placeholder for a different implementation. In general wiring up is not as elegant as I would haver liked.

Ok, but where is the code?

I’ve started a project on GitHub. It’s called D3N. You can find it there. It's still naive, but I’ve tried to do things well and started to post also issues about the things I want to cover/experiment in the next weeks. At the end I am thinking more about a playground than a “sample app” (I hate this term).
So far, there's not so much to see, but I've been writing a hell of a long post. Let's try to get more use cases implemented and more coverage of the actual evolution. As I said before, there’s a lot more in doing a DDD application than just the resulting code.

As somebody once said: it’s the journey, not the destination.

Denial won't help you learning

While preparing my talk (video) for the last Italian Agile Day conference, I spent some time retrospecting on my past projects. As people who attended know, this retrospective step ended up completely thwarting the original purpose of the speech: looking back in the past I discovered more than I expected.

To be completely honest, some of the inspiration for the talk came from Alistair Cockburn closing keynote at JAOO 2007 , I rarely invent anything. Connecting the dots is my job.

My key factors for successful learning

(OMG, I wrote this title like I know this stuff... and I actually don’t) While retrospecting on my past projects, I didn’t focus on normal success conditions. I focused on the amount of relevant knowledge learnt during the project. This allowed me to look at the past with a different perspective, seeing things that I probably overlooked in the past. From the perspective of learning, the key factors that most influenced the outcome were:

1. Team attitude
2. Motivation
3. Context.

Team attitude is a tricky definition. Because it states 2 different things: that the attitude is relevant, and that I actually need a team. Of course I’ve learnt a lot also in projects where I was a lone consultant: I did some stuff, I solved some problems, I spent some time thinking about what I actually did. But the real massive amount of learning happened in projects where I had the chance to solve complex problems as a team.

Interestingly I couldn’t find any connection to the role I was playing at that time. Didn’t really made a difference if I was a junior developer or a project manager, or a senior architect. Didn’t really made a difference if I was supposed to be managed or managing (I hate this definition, but that used to be the past). Didn’t really made a difference if I was supposed to learn from the colleagues or to teach them something.

The one single thing that made a lot of difference was the attitude me and my colleagues shared in those difficult projects.

Learning attitude patterns

People made a lot of difference also in the business outcome of the project (yes, that boring on-time and on-budget part) but could give me from the very beginning a grasp about what I was going to expect. Let’s make some examples with somewhat stereotypical approaches.

“I know what I am talking about” that the kind of sentence often heard in organizations. To me, it means “I don’t feel any need to improve”. I’ve met some person like this, but luckily they were not in my team. Sometimes they were part of the organization we were supposed to work for, almost always they were part of the problem. I don’t want hem in my team. Plain and simple.

“That’s all clear to me” ... No. It isn’t. People that for some reasons pretend they’ve understood everything needed to solve the problem, are part of the problem as well. Quite often, under the surface they look for hints about what the boss said, and keep pretending that everything is fine. Walking timebombs.

“I have no clue about what we’re going to do” Now we’re talking! The most effective colleagues I’ve worked with always started the project with fear. They called me out for a one on one talk, and with fearful eyes told me “I know absolutely nothing about the topic of this project”, and - believe me - their faces were even better when I answered honestly “I have no idea about it either”. But that conversation was honest, we defined a common ground, and we started learning collaboratively assuming that we didn’t know all the things and that we needed to share information to solve a common problem.

Confront this profile with the previous two. Would you share information with those colleagues also? A lot less, ...they won’t need it anyway: they (pretended/assumed) that they already know the stuff. They basically shut themselves out from any possibility of collaborative learning. Ok, that’s basically Socrates statement: “The real wise man is the one that knows that he doesn’t know”. ...But not only.

Focusing efforts in the right direction

What’s striking me more and more, is that the attitude we had sometime towards learning new things as a team, was incredibly effective also because it was efficient. We din’t waste any time in pretending that we were better than we really were. We did have a massive amount of work to do, but we didn’t have any knowledge debt, and we didn’t spend a second studying things that people around me expect me to know but I don’t.

Don’t you smell something familiar here? It smells like your dirty little secret to me. Make me think about movies where one of the characters did something wrong in the past and lives in the fear of being blackmailed... Ignoring a key skill, it’s not as bad as committing a crime, but the mechanics in our mind are not that different. Our brain start working in “I can’t let them discover my secret" mode, which is a dangerous slope: it makes you feel like “I am not the person they expect”.

It doesn’t matter how bad is our secret, the mechanics are similar: shame and fear of humiliation (even if only at the coffee machine level) are powerful triggers, and would lead to the wrong behavior, and also to learn less in the long run. Because stress is preventing from effective learning, because one can’t enjoy collaborative learning, and because a lot of time won’t be dedicated to learning but just to cover-my-ass activities which are brain draining (how many brain cycles are you spending deleting compromising SMS from your phone or wondering if your girlfriend can actually see what you posted on that other girl's wall on Facebook?).

To be honest, in a software project, your fault (if we want to call it like that) is really little. Telling that you’ve actually never understood OOP, or that you’ve never actually shipped anything to production isn’t a fault, it’s just a honest starting point. Stating where you are exactly and honestly right now would save you and your team a lot of troubles in the future.

When is the moment of staffing the team for a new project. Now I know exactly what I want. I want people with the right learning attitude.

Only knowledge gap?

Not really. The more I look into the problem, the more I realize that the mechanics are the same whether it is knowledge or learning debt, technical debt or motivational debt. Failing to acknowledge where we really are only exacerbates the problem. But that’s a topic for a whole new post. I also didn’t say much about motivation and context... Stay tuned.

 

See the Forest and the trees with Kanban

I uploaded the slides of my presentation about Kanban that I gave at last UGI Alt.Net Conf in Milan.

Forest and trees with kanban

View more presentations from Alberto Brandolini.

Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Event Sourcing

Here are the slides of my presentation about CQRS and Event Sourcing, that I gave at NHibernate Day in Bologna last week.

Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Event Sourcing

View more presentations from Alberto Brandolini.

And if you're masochistic enough to stand my accent ...here is the video.

DDD Reference Links

Further references

Books

Domain Driven Design - Eric Evans (Addison Wesley)

The official starting point for Domain Driven Design, covering the topic form tactical to strategical.

Applying Domain-Driven Design and Patterns (Addison Wesley)

A more implementation related approach focusing on the mechanics of the implementation of tactical DDD with C# and .Net.

DDD Quickly

A free dowloadable smaller reference for Tactical DDD from InfoQ

http://www.infoq.com/minibooks/domain-driven-design-quickly

Domain Driven Design website

New official website for Domain Driven Design. Aggregator for further resources, informations, discussion and events

http://domaindrivendesign.org/

Domain Driven Design User Group

This is the place where the most interesting discussions are hosted

http://tech.groups.yahoo.com/group/domaindrivendesign/

Italian Domain Driven Design group

http://it.groups.yahoo.com/group/DDD-IT/

Eric Evans interviews and talks on InfoQ

http://www.infoq.com/interviews/domain-driven-design-eric-evans

http://www.infoq.com/presentations/model-to-work-evans

http://www.infoq.com/articles/eric-evans-ddd-matters-today

http://www.infoq.com/presentations/strategic-design-evans

http://www.infoq.com/presentations/ddd-dsl-evans

DDD sample Application

A working implementation of DDD principles in SpringMVC plus Hibernate, maintained by Swedish company Citerus.

http://dddsample.sourceforge.net/

CQRS & Event Sourcing

I needed a separate page for that:

http://ziobrando.blogspot.com/2010/10/cqrs-event-sourcing-reference-links.html

DDD, TDD & BDD

The three amigos: DDD, TDD & BDD Presentation by Gojko Adzic

http://skillsmatter.com/podcast/design-architecture/ddd-tdd-bdd

Gojko Adzic’s Blog: http://gojko.net/

Context mapping

Strategic Domain Driven Design with Context mapping (My article on InfoQ)

http://www.infoq.com/articles/ddd-contextmapping

Context Mapping in Action - Presentation by Alberto Brandolini

http://skillsmatter.com/podcast/design-architecture/context-mapping-in-action

Articles

About entities, aggregates and data duplication - Alberto Brandolini’s blog

http://ziobrando.blogspot.com/2010/06/about-entities-aggregates-and-data.html

Random Links

Kent Beck blog entry on why writing maintainable software matters.

http://www.threeriversinstitute.org/blog/?p=104

Some more related or interesting books

Patterns of Enterprise Application Architecture - Martin Fowler

Analysis Patterns - Martin Fowler

Growing Object Oriented Software, guided by tests - Steve Freeman & Nat Pryce

The Pragmatic Programmer - Dave Thomas and Andy Hunt

Clean Code - Robert C. Martin

Agile Software Development, Pattern Principles and Patterns

 

Lean Software Development - Mary and Tom Poppendieck

Test Driven Development by Example - Kent Beck

Collaboration Explained - Jean Tabaka