Ziobrando's Lair

Setting up a DDD sample app

2012-01-02T16:56:00.001+01:00

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:

gather some information from the domain expert about features A, B and C;
quickly implement it as a domain model, using DDD patterns;
spot contradictions in the current understanding of the domain, that emerge from the model;
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

2011-11-30T12:01:00.001+01:00

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:

Team attitude
Motivation
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

2011-03-07T23:22:00.001+01:00

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

2010-10-17T10:13:00.001+02:00

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

2010-10-12T14:23:00.001+02:00

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

CQRS & Event Sourcing Reference Links

2010-10-12T14:21:00.001+02:00

CQRS & Event Sourcing

DDD/CQRS Mailing list

The official CQRS Website

Interviews

Eric’s interview to Greg Younghttp://www.infoq.com/interviews/Architecture-Eric-Evans-Interviews-Greg-Young

Clarified CQRS - Article by Udi Dahan

Presentations

Command Query Responsibility Segregation - Presentation by Udi Dahan
http://www.infoq.com/presentations/Command-Query-Responsibility-SegregationAvoid a failed SOA - Presentation by Udi Dahan

http://www.infoq.com/presentations/SOA-Business-Autonomous-Components

Event Sourcing

Event Sourcing definition by Martin Fowler

http://martinfowler.com/eaaDev/EventSourcing.html

Innovation and Event Sourcing - Greg Young presentation

http://skillsmatter.com/podcast/design-architecture/architectural-innovation-eventing-event-sourcing

Code References

Super Simple CQRS Example

http://codebetter.com/blogs/gregyoung/archive/2010/08/31/super-simple-cqrs-example.aspx

Agile Testing UK meetup

2010-06-16T09:35:00.002+02:00

While in England for DDD Exchange, I caught the opportunity to participate in a meetup of the UK Agile Testing community. Gojko Adzic led a very interesting workshop about how to write acceptance tests.

Neil McLaughlin, who happened to be in my team in the hands-on simulation wrote a nice report on the evening, and then Gojko himself posted about what he showed us. I'll try add something, from the participant perspective.

The developer mindset

Given we had quite a few people in the room, around 60, it was really interesting to note all different behaviors, but there were also some striking similarities. Most of the discussion we had were focused on

Formal correctness of the test
Splitting tests to be testing one concern at that time
avoiding duplication in test fixture setup

When discussing the outcome, Gojko pointed out that the main concern for acceptance tests was readability, instead. Readability is a subjective evaluation criteria, and might lead to a not-so-precise definition about how to make it right. But that's the only way to write a useful acceptance test. But the developer's mindset really had a strong influence on us, it was really hard to give up.

Constrained by the tools

Despite Skills Matter (that was hosting the evening) doing a fantastic job in providing an impressive amount of whiteboards for all the team, some of the discussions were constrained by the amount of space available on the whiteboard, so we ended up pruning some concerns, thinking they were of little value to the discussion. It turned out we were wrong.

But, as I said, we had an amount of writable space that was a lot larger than what I normally found in a typical workplace... and still this was constraining us. Buying one more whiteboard is cheap, making wrong assumptions because of writable space constraints is a lot more costly.

We're problem solvers, after all

During the exercise, Gojko was wandering around from one team to another one, playing the role of the Domain Expert. However, most of the teams seemed more interested in his Teacher role and asked some questions about how to solve the exercise, but barely none about ambiguities in the domain. We preferred to use assumptions instead.

Even if I knew the trick, it worked on me as well. But it's scary to note that even when writing acceptance tests, which are a lot more translation than design, our built-in problem solving brain leads us so easily on the road of guessing instead of asking.

About Entities, Aggregates and Data Duplication.

2010-06-15T18:41:00.006+02:00

There's been an interesting discussion about Aggregates on the Italian DDD mailing lists. When things become complex, a simple example might just turn too simple. So I came up with this medium-sized one. Hope it won't be too long. Ok, so let's start from our first User Story

User Story #1: Placing an order
As a Customer
I Want to place an order
In order to purchase some goods

The simplest implementation of the story is essentially stateless: every time a customer wants to order something, needs to re-enter the data. In the DDD perspective, the resulting model is based on a single aggregate (we're deliberately ignoring the catalog for now) whose root is the Order class.

The stateless nature of the service makes it really easy to implement: a Customer is just a Value Object, created and eventually dropped at needs. Also we took some shortcut: we've chosen to implement Address as a String. Item is sort of natural value object, while LineItem is somewhat in the middle: we can change quantities, while the order is in open state, but we can implement this also using droppable Value Objects, easing the integrity burden for the aggregate root.

Some businesses (like buying train tickets) might just work like this, but our marketing is more inclined to manage customers in a more long-term way, so here are two more user stories.

User Story #2: Returning customer
As a Customer
I Want to retrieve my profile
In order to place more orders

Story #2 breaks our assumption about the aggregate boundaries. If we stick to the aggregate rule-of-thumb, if we want to delete an Order, we probably don't want to delete also the corresponding Customer. So we need a separate aggregate for that. What would happen if we decide to delete a Customer? Should we delete all orders? We don't have enough information to answer that, yet, we'll mark it as an outstanding question for our next meeting with the domain expert. Let's try the model with two aggregates and see how does it perform.

We now have a relationship crossing the aggregate boundary. We have promoted Customer to become the root of the newly created aggregate, so there is no potential integrity violation. Still we have to watch it closely, because this is where problems related to lazy/eager loading will arise. We also added username and password to Customer.

User Story #3: Different shipping address
As a Customer
I Want to specify a valid shipping address
In order to ship to a different destination

Multiple addresses are a call for a separate type to manage Address. We don't have so many responsibilities so far, for this class, except validation (which as Udi Dahan would say, doesn't necessarily belong to the domain layer) but the smell of duplication is probably enough to go for a separate class. We try to keep the model as simple as possible, so we treat Address like a value object.

User Story #4: Editable customer profile
As a Customer
I Want to edit my profile
In order to update it if needed

Story #4 makes explicit what we've been suspecting: Customer needs to be an entity, because it has a nontrivial lifecycle. No revolutions at Domain Model level, but this triggers a question: "What happens if I have an outstanding order and the customer changes its data before the order is dispatched?" This is the type of questions you don't want to answer as software developer. So we walk up the stairs to have a talk with the Domain Expert. We come back with two fresh user stories:

User Story #5: Specify Billing and Shipping address
As a Customer
I Want to specify independent billing and shipping addresses
In order to deliver goods to different locations

This one is relatively easy: just reinforcing our design. We'll now have two references from Order to Address, which are managed by the Customer. We just store a default Address in the Customer aggregate (we could do better) but's ok for now.

Story #6 is a little trickier, it comes from the legal department and tell us what we probably expected.

User Story #6: Track past orders
As a Legal Department
I Want to track orders
In order to in order to manage litigations

The domain expert state it clear: once an order is placed, it can't be changed in any of its parts, be it the content or the Customer. In case of litigation, it must behave exactly like printed paper. But Customer does not, its lifecycle is different from our needs, we'd need a separate class for that. We're lacking fantasy and call it CustomerData.

Everything is looking a lot different from the beginning. The two aggregates are now largely decoupled: we can change or delete an order without affecting the customer or deleting or unregistering a customer without losing tracks of its past orders. On the other hand we have explicit duplication here. Customer and CustomerData look so similar we're feeling guilty. Did we violate DRY principle? At first look the data is the same, but if we think about behavior, or class lifecycle, Customer and CustomerData are clearly two different beasts. But more often than not, when the starting point is the data model, instead of the domain model we end up thinking that's the same data, hence the same class. I bet experienced data modelers do not fall into these pitfalls as well, but I've seen these problems recurring quite often.

Once we accept that little bit of data duplication we have a system which is a lot easier to evolve and maintain, with aggregate roots as integrity enforcers within their boundaries, and agnostic about the rest.

To add some salt, don't forget aggregates are also building blocks of distributed systems: suppose we'll need to send orders to a remote system. Sending just the single aggregate and the referenced value objects is probably the cleanest way.

Software ...e tutto ciò che comporta

2010-05-07T18:32:00.001+02:00

Here are the slides from my presentation in Better Software 2010. I tuned it up a bit, changed the grey text, added comments (in italian) and a couple of slides. Hope you'll enjoy it.

Software ...e tutto ciò che comporta

View more presentations from Alberto Brandolini.

Some thoughts on the iPad

2010-02-02T09:50:00.001+01:00

Last week the Net was in "full hype mode" for the launch of the latest Apple device. The outcome anyway is rather controversial, maybe expectations were set too high, leaving somebody down.

Only time and revenues will tell who's right: but I think a few things that emerged from recent discussions are worth thinking about.

It's all about being sexy

What's the ugliest part of an electronic device? Cables. They're messy, and despite every effort to make them look pleasant ...they are ugly, and probably always will. I suspect that the lack of connectors is a way to discourage users from plugging in many devices: famous actresses look a lot more ordinary without the make up. And they hate showing up in public if they have some imperfections on the skin. It's called vanity. The best way to satisfy vanity is to make the iPad an essentially wireless device. Cables are for losers, they're necessary, but only when nobody's watching.

However, if you still feel like you need to upload pictures, connect to external devices... you'll maybe end up buying another device like the AirPort.

Gestures matters

Some folks complained it's less than an iPhone. Wow ...it's big! Do you really would like to phone with a big device like this? It doesn't feel natural. Our body learned to associate gestures with situations, and we phone with small objects (like ...phones) and we read with bigger ones (like magazines, books and newspapers). I think the whole idea is to make the device feel natural. Things or actions that wouldn't fit the device were simply not included.
Looks like the whole idea is to be a device do be used on the couch. Relaxed, and quiet. Like ...reading a book, but not necessarily so.

A pleasant experience

iBook and the relative store, are more than a hint that Apple is engaging Amazon in the book battle. Some friends noted that reading a book requires a different display, to be a pleasant experience for the eye. I think they're right on this. Sill the iPad is not a device to do one thing (as it is for Kindle) but to do many. And not all of them are necessarily known from the beginning.

No multitasking

Some people consider the lack of multitasking capabilities as a key missing feature on the iPad. I think the opposite. Frequent interruptions are stressing, and to me the iPad looks like a thing to do one thing at a time (which by the way is the basic mantra of GTD, Kanban and so on). If you want to torture yourself by being continuously interrupted, a phone or a PC are the tools for you, and this is what you probably use for working. But if you want to please yourself, relaxing on the couch, the only other thing to do while using the iPad is probably having a glass of good wine. Or maybe that's the picture of you that will stick in your brain to make you buy that thing.
I suspect that also the lack of a camera has something to do with that. I mean ...Apple put cameras in MacBooks ages ago: they know how to build devices with cameras. But the stressing feeling of being continuously reachable is what makes people hate cell phones. A device that allows you to surf/read without being interrupted that often, could be loved by some.

It's not for the geeks

Maybe I am a little bit too far on this, but I think the iPad is targeted to a part of the market that had been partially untouched from other Apple products. Think about the agenda: it really feels like a real agenda, with all the potential of an application. There are quite a few users that still prefer planning on paper rather than on a blackberry or an iPhone, cause you don't see the whole picture there. More generally, geeks feel comfortable with complexity and multitasking. Many folks don't.

I have to admit i bought the iPhone for 2 reasons: learning and vanity. The reasons I use it now are completely different, and I discovered them while using it. So I think it's still early to have a precise idea of the potential, and of the marketing success, but really looks like "less is more" has been a design driver this time.

We can do better than this... Reloaded

2010-01-12T15:52:00.002+01:00

In the last Italian Agile Day I delivered an open presentation called "Possiamo fare di meglio" (this post's title is just the translation), where I raised some questions about the way we develop software. I then tried to summarize some of the things that emerged in the discussion here, but there are still many things that are bouncing in my head...

One thing that really disappoints me is the low quality of many software applications I have to deal with in my everyday life. Some days I really feel like I am surrounded by crap. Just to make it clear what I am talking about: here is an excerpt of what a home banking service is asking me every single operation I do.

Choose the desired account:

And every time I think: "It's one account, it's just one account, it's always been just one account, so why on Earth you keep asking me this question every time! Couldn't you just take me straight to the account...".

Some days I just feel like surrender, some other I see how some application are doing a fantastic job, on platforms like iPhone or on the web, and I feel like there's still some hope for us.

There is still a lot to do

Despite all of our efforts, to introduce TDD and continuous integration, velocity based estimations and the like. There's a lot to do in other fields as well. Let me say it in another way: many companies are looking towards agile methodologies as a way to improve their development processes, in order to deliver software on time and on budget.

Doesn't sound that bad isn't it?

It does. It doesn't mention the quality of the product. ...Oh, yes, we forgot, we need also tests to reduce our defect ratio. Tests are good, software quality is good, but still doesn't address the whole point. We should deliver better products. Emphasis on the process itself would satisfy the managers' ancient need for schedules and predictable outcome, allowing teams to produce crap more efficiently, but would not produce better products unless some key points are specifically addressed.

The most neglected areas at the moment - at least from my point of observation - are:

user's involvment,
understanding the domain complexity,
lack of an overall perspective,
inefficient learning during the product development lifecycle.

The items are not completely separated, in fact they're slightly overlapping, but I think these are the areas where as software developers we can (and must) improve a lot.

In the next posts I'll dig deeper in these topics.

New DDD training events in Bologna

2010-01-04T17:28:00.004+01:00

The first dates for Domain Driven Design classes in Bologna are finally published!

1 introduction day, targeted to who want's to know what DDD is, on February 8th (info & registration)
4 days of workshop from February 9th to 12th for practitioners that want to dig deeper and discuss (info & registration)

The events will take place in Savoia Regency Hotel (well known to participants of last Italian Agile Day). Early bird till January 15th, and special discounts for Bologna XPUG menbers.

DDD patterns as “elegant support”

2009-12-16T18:56:00.003+01:00

I've got quite a challenging response to my article about context mapping on InfoQ, that forced me to re-think about the article, and re-express some concepts, because some statements could have been misleading. I quickly mentioned the “classical” or “tactical” DDD patterns, such as Aggregates and Repositories and it looked like they’re the key to successful design. Well, they do help a lot, but the key to successfully implement a domain model is to understand the domain, achieving a creative collaboration with the domain expert. Practically this produces a small, but sophisticated, domain model that deeply reflects our understanding of the domain and supports our future, business-driven, changes. It’s impressive to see how a well designed model can accommodate changes.

So, the whole point is to keep your model tidy, small and clean. Most of the tactical DDD patterns serve the goal of keeping the domain model clean. Classes like Factories or Repositories, belong in the domain layer, have a well defined responsibility, but I think their overall purpose is to allow for the cleanest possible programming style in Entities and Value Objects, where most of the domain behavior is coded. In a certain way, the whole system of patterns is a sort of necessary scaffolding to allow the domain model to thrive. Patterns are not part of discussion with users and domain experts (this is pretty obvious, but ...zealots are zealots), they’re just part of the implementation. They allow the model to be technology independent, or decoupled from other portions of the application, they allow the model to be easily tested. They allow for complexity to be managed in an elegant and scalable way.

Sometimes elegance might be a problem
There is some aesthetic quality in a well crafted domain model. Some developers really like what a DDD model will look like. Guess what? I like it too. But that might deviate our attention to what really matters. Sometimes elegance has no business value, or better, is perceived to have none, by non-developers.

“We’re refactoring this architecture to make it more elegant”
“I don’t pay you to write Armani-dressed code! I want code that works and I want it fast!”

Has any of us developers being seduced by the beauty of numbers in an Excel balance sheet from the finance department? I guess not. It’s just a different language. So, sometimes it’s better to express “elegance” as “reducing the cost of change”. Sounds a lot more like business, and a lot less like a disconnected geek spending the time tidying up the code (by the way also cleanup doesn’t really work). We’ll still implement elegantly, but that’s our job.

So if you’re enthusiastically embracing DDD and try to apply what you’ve read in the book, be careful not to transform yourself in a DDD pattern zealot. Their elegance might distract attention from the real goal: they’re helpful and often indispensable, but the real target is in the domain itself, and in it’s business value.

Video of my "Possiamo fare di meglio" speech is out.

2009-12-01T12:34:00.002+01:00

Big thanks to Yuri Valentini and all the friends from the Bologna XP User Group, for editing and posting the video. Here's the link.

Shared the Agile Day Presentation

2009-11-26T17:02:00.002+01:00

The Slideshare version of my "Possiamo fare di meglio" (we can do better than this) presentation, is now available (in Italian) here.

I did my best to add comments to the many pictures, sooner or later also the video version will be available.

Article on DDD Context Mapping is out on InfoQ

2009-11-25T10:32:00.002+01:00

We've been talking about Context Mapping quite a lot in the last days, I was also writing a lot in the meanwhile. The article I wrote for InfoQ is finally live.
Thanks to Srini Penchikala for taking care of me and of my messy review process.

A crowdsourcing experiment

2009-11-23T19:30:00.002+01:00

Like one year ago, I decided to give my talk at Italian Agile Day as an open session with roughly the same schema: 15-20 minutes of impact talk, and 30 minutes of open discussion. I like this type of sessions because it’s not a “I know the truth” approach (I don't), but rather a way to make a small portion of a possible truth emerge from anyone in the room. So, even if I had some answers in mind, I preferred to focus on the questions, leaving the answers eventually open. I’ve seen some open sessions, but it’s not the kind of things that you practice every week (unless you’re leading a talk show), so please forgive me if it anything went wrong. Personally, I think it went a lot better than the year before: the discussion flew naturally and touched many of the topics I wanted to touch.

See it in another way
Ok, now think of me like Dr.Evil, with a “masterplan”: I’ve managed to hire about 200 among the best IT professionals I know as consultants for one hour. Basically for free. That’s my crowdsourcing experiment. And I had the feeling of so many little things emerged. Maybe not so clearly, maybe not so well formed or well expressed, but enough to make me think a lot in the following days.

On the way home, and later in the weekend some thoughts were a little clearer. I guess my personal follow up is worth sharing: at least ...I owe it to the participants. :-)

We’re making products, not software
Software is what we know, what we like to write, what we learned to produce. Some of us are really good in writing software, or in making their team write good software. That’s only half of the story: from the user perspective we see a product, not code. In the discussion, many mentioned user interface or the user experience. Which is right. But it’s still trees, not the forest. If we start thinking about the overall product we might realize that we need to see the whole a lot better than we usually do. Scrum has a good shoot on this by emphasizing the role of the Product Owner, meaning that we have a single responsible person (which is a gift from the gods in many organizations) for the whole product. There’s a problem up there, because so many times the whole idea of product is flawed, and we’re just writing software. Guess what... with a high probability of being completely useless.

I’ve seen so many projects missing their goals or their potential, just because the responsible organization didn’t have a clear idea of the whole product not to see a pattern here.

Non technical integration is not so easy
Ok, so we should try to have an all-round view to our product. Including also non developers roles within our project scope. Interesting but tricky. Especially if the team boundaries do not match with the company boundaries, which might happen quite often in a cross-functional team. But software-only teams can control continuous integration to a very high degree of efficiency using TDD, Continuous Integration and SCM tools. But this is only a portion of the product. Other professional might follow a different approach, that has nothing to do with TDD (or maybe it has... only on a different time scale), and the perfection we strived to achieve becomes frustratingly fragile. I guess there’s no easy recipe here, we’ve got to fall back on mantras like “inspect and adapt”: solutions might be a lot different from team to team. After all we’re humans. But it’s funny to realize that we sometimes we want to “integrate early and often” but “only software artifacts, please”. Postponing integration with non-software components of your project is even riskier.

This is definitely a hot topic, especially if you approach it from an enterprise management perspective: enterprise 2.0 folks are talking about more flexible approaches to collaboration, and this might be at odds with the benefit of a jelled team.

Reading suggestions after IAD2009

2009-11-23T17:53:00.002+01:00

I’ve found myself talking about many different books with many different persons during IAD2009, here’s a summary of the books I more or less explicitly suggested:

Pragmatic Thinking and Learning - Andy Hunt: some things happen by chance, some don’t some others you could make it happen.
Agile Software Development, the cooperative game - Alistair Cockburn: an eye-opener on what’s around the code.
Agile Retrospectives - Esther Derby, Diana Larsen: so little small details can make the difference between a good retrospective and a useless bloodbath.
Collaboration Explained - Jean Tabaka: sometimes there’s so much about the people that we don’t really know.
Agile Project Management with Scrum - Ken Schwaber: it’s not software development, it’s product development.
Don’t Make Me Think - Steve Krug: how many times are we willing to transform a service into a pain?
The design of everyday things - Donald A. Norman: guys, I hate bad design.
Domain Driven Design - Eric Evans: there’s much more to this book than it looks (and looks like there’s plenty of stuff already).
Patterns of Enterprise Application Architecture - Martin Fowler: the reference book for current architectural patterns.
Agile Project Management - Jim Highsmith: it’s not all about the software,but it works.
Slack - Tom de Marco: oops seems like so many things your organization is doing are wrong.
Peopleware - Tom de Marco, Timothy Lister: still incredibly useful, if you haven’t read it you’re just pretending to manage software projects.
Getting Things Done - David Allen: everybody’s talking about GTD, maybe because there’s something true in that.
Clean Code - Robert C.Martin: you won’t go anywhere if you don’t agree on this.

Hope these might be useful to some.

Back from the Italian Agile Day 2009

2009-11-23T17:01:00.000+01:00

I’ve seen skilled and curious colleagues. I’ve seen nice ideas emerge from different perspectives (more on this soon). I’ve met old friends and nice persons which I didn’t know and that I am now honored to know.

All this doesn’t happen everyday and everywhere.

Thanks to Marco Abis that every year make this magic happen. Thanks to everybody in the staff and to all friends from the Bologna XP Users Group, once more fantastic. Thanks to all the speakers, able to tell real stories without hype or fluff. Thanks to all the participants to my “talk show” sharing interesting ideas and thoughts. Thanks to the heroes that risked asphyxia to follow my Domain Driven Design mini-workshop.

Thanks also to Roberto Bettazzoni that reminded me what it means to be “Romagnolo”.

It has been a great day.

Thanks to everybody made it possible.

Scrum Introduction with Peter Stevens

2009-11-02T14:04:00.003+01:00

As a satellite event to the 2009 Italian Agile Day in Bologna, I'll be helping Peter Stevens in the one day Introduction to Scrum that'll take place in Bologna on November 19th, right before the IAD.

Peter is a seasoned Scrum trainer based in Switzerland, and helping companies in different countries. More info could be found on his blog Scrum Breakfast.

Peter speaks quite a good Italian, we thought that the best combination would be to keep the teaching part in English, and question time in Italian. But ...I guess this would be an emerging behaviour as well.

By the way, Agile Day participants will get a 20% discount on the full price.

JAX Italia 2009

2009-10-21T17:26:00.004+02:00

Event agenda is getting crowded: in November I'll also be speaking at the first edition of the Italian JAX Conference, I'll be giving a talk about Domain Driven Design, and a full-day DDD seminar on Saturday 14th.

Some more detailed info here.

Italian Agile Day 2009

2009-10-20T15:13:00.003+02:00

Registrations are open for the Italian Agile Day 2009, still in Bologna on November 20th.

I'll be giving a talk "Possiamo fare di meglio" (We can do better than this) and maybe a short workshop. Everybody interested in agile software development is warmly welcome. Hurry up!

Fast and Slim Enterprise 2.0

2009-07-03T22:28:00.002+02:00

Next Friday - July 10th 2009 - I'll be participating to a public debate in Bologna (Palazzo Gnudi at 17.30) about the Enterprise 2.0 topic. Speaker panel looks promising, and the event is free :-)

Software house Gecod is hosting the event, more information on the official event page.

So ...what exactly is a context? - Part 1

2009-06-29T21:30:00.012+02:00

One of the premises of Strategic Domain Driven Design is that in every non-trivial application there will be multiple models at play. This may sound controversial to some, but since a model is a representation of a portion of the problem domain aimed to serve a specific use, the need of multiple models promptly arises as our application grows in size and/or complexity.

The Ubiquitous Language plays many roles in DDD, among others it may be considered an integrity check for any model in play assuring that every role involved in software development, from domain experts to developers, shares the same language and agrees on the specific meaning of every term which is part of the ubiquitous language.

The Ubiquitous Language should be the only language used to express a model. Everybody in the team should be able to agree on every specific term without ambiguities.

Code is the primary expression of the model, other artifacts might be necessary along the way to capture requirements or portions of the design, but the only artifact that will be constantly in sync with the application behavior is code itself. Ensuring that every term is precisely defined and that is consistently used in every representation of the model greatly helps ensuring integrity of our application. Model integrity comes at a (reasonable) price: the model cannot be extended indefinitely, but can be shared, coherent and acknowledged only within a given Context.

So, ...what exactly is a context?

In Domain Driven Design, a Context is defined as

“The setting in which a word or a statement appears that determines its meaning”

which might sound rather ...vague, at first read. But I’ve learnt that Eric Evans always chooses carefully each word, especially in the key sentences. So the definition above describes exactly what a context is (at least in the Domain Driven Design context). This definition says nothing about the size, shape or other characteristics of a context, so they are likely to be consequences of the link between the word or the statement and the meaning.

But this definition calls for examples, here is a trivial one. The word Account has a very precise meaning in the banking context, and in a typical application, we would probably model it with a balance and an accountNumber attribute, and so on. But in the context of Web Applications, an Account is closely related to credentials, such as username, password, and so on, and we would tend to model it in a very different way.

Trying to force the two definition within a single class might result in awkward code, whose conceptual integrity has been undermined by the attempt to fulfill two distinct models within the same class. Admitting that the same term might be referred to two distinct concepts is crucial for model integrity.

Making the contexts explicit, we are making both models clearer and unambiguous.

The term Account does not have a single non ambiguous meaning, but in a given context the meaning is well defined.

Ok, this first example might be too trivial: the term Account refers to two different concepts, and simply calling them BankingAccount and LoginAccount might have solved the problem. A more subtle distinction might arise when the concepts is the same but but used in different ways, thus leading to different models.

Let’s suppose we’re working with an application managing payments. We’ll probably use this application to manage our Banking Accounts, keeping track of current balance and past operations. The model for our Banking Account might be a BankingAccount class like the one below.

Some PFM apps allow us to manage also payments, keeping a Payee Registry. In this scenario, a Payee is normally associated with one or more Banking Account, but in this case we won’t know anything of the internals nor we can issue any operation on those accounts. Does it make sense to model the Payee account with the BankingAccount class we’ve just defined?

Well... it does sound reasonable: it’s the same concept, I mean, in the real world our account and the payee’s one might even be in the same physical bank. Still, it doesn’t feel completely right: we are not supposed to issue any operation on the payee Banking Account, or to track anything on that. Even worse: doing so would probably be a bad mistake within our application.

In this case, we’re using the same concept in different ways, and this will lead us to different models. Even if the class is already defined in the application, a different context calls for a different model.

Again, name clashes might be solved in different ways at the code level, you can effectively partition the system by adding meaningful prefixes to the classes, or using packages, or in some other way. What matters now is that there are ambiguities, and a term can be effectively defined only within a given space.

So, a Context is a “space” where a given concept is precisely defined without ambiguities, so that it can be safely used in the Ubiquitous Language. If the same concept appears different times with different meanings within an application, we’re probably heading towards multiple Bounded Contexts within the same application.

In Domain Driven Design, a model is intended to serve a specific use, and nontrivial applications often tend to be used in different ways: trying to accommodate every use within a single model is a meaningless effort. It will end up corrupting your model with ill-defined or ambiguous term making the model you developed within a context less valuable. Contexts cannot be expanded indefinitely: Context Boundaries are needed to define which concepts are in and which ones are out, and to ensure conceptual integrity to the model within the context.

Back from the London DDD-Exchange

2009-06-23T16:44:00.003+02:00

I just came back from London where Gojko Adzic and I led a 4-day full immersion Domain Driven Design class in Skills Matter HQ. Wasn’t it enough, on friday we had the first edition of DDD-Exchange, in the Crypt with quite a few interested participants.

First of all, I’ve got to thank everybody in Skills Matter for the fantastic job. Organization was incredibly efficient with wi-fi, food and beverages, real-time twitter coverage and quick publishing of the talks on the company website (mine is here). Despite a long line of sleepless nights working on the presentation and my terrible accent, looks like everything went fine. We had quite a few interesting talks, and I also participated to my first park bench panel, which turned out being quite interesting and open ended. Also, beers with some of the folks that came to attend the DDD-Exchange were even more open ended.

So, despite being incredibly tired, at the end I felt like I did something good, many people actually liked my presentation and we had many interesting discussions during the breaks.

By the way I uploaded my presentation on Slideshare, after making some small corrections and adding some notes to prevent possible misunderstandings.

Tags: DDD, Software Development, Agile, Project Management

Ziobrando's Lair

Setting up a DDD sample app

Why should I regret it?

Choosing a domain

Choosing a programming language

Providing a little structure

Modeling question number one

Ruby, the architecture and me

Persistence framework

What I like so far

What I don’t like so far

Ok, but where is the code?

Denial won't help you learning

My key factors for successful learning

Learning attitude patterns

Focusing efforts in the right direction

Only knowledge gap?

See the Forest and the trees with Kanban

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

DDD Reference Links

CQRS & Event Sourcing

CQRS & Event Sourcing Reference Links

﻿CQRS & Event Sourcing

DDD/CQRS Mailing list

Interviews

Presentations

Event Sourcing

Code References

Agile Testing UK meetup

The developer mindset

Constrained by the tools

We're problem solvers, after all

About Entities, Aggregates and Data Duplication.

Software ...e tutto ciò che comporta

Some thoughts on the iPad

It's all about being sexy

Gestures matters

A pleasant experience

No multitasking

It's not for the geeks

We can do better than this... Reloaded

There is still a lot to do

New DDD training events in Bologna

DDD patterns as “elegant support”

Video of my "Possiamo fare di meglio" speech is out.

Shared the Agile Day Presentation

Article on DDD Context Mapping is out on InfoQ

A crowdsourcing experiment

Reading suggestions after IAD2009

Back from the Italian Agile Day 2009

Scrum Introduction with Peter Stevens

JAX Italia 2009

Italian Agile Day 2009

Fast and Slim Enterprise 2.0

So ...what exactly is a context? - Part 1

Back from the London DDD-Exchange

CQRS & Event Sourcing