f3yourmind

I just had a quick Google Wave experience with Willem Odendaal and the experience of seeing the other person type was a bit weird for both of us.

Lesson to both of us: Think before you wave!

Also, I have to remind myself to not think about waves as email, or tweets or instant messages. It’s just something else! And it has a different spin on the time dimension of communication.

I suspect that Google Wave will force us to be better at the way we communicate, how we express ourselves and the relevance of the content to the conversation.  I can imagine a wave growing over time that describes a story started by a domain expert with feedback from a developer and a nice cadence emerging between them.  It all is in one nice wave, with playback that tells you how you got there in the first place.  I wonder if this will have an influence on effectiveness of remote pairing?

I also have a feeling that if you’re a waterfall type of person, then waves will not have an impact on you.  It’s all about feedback and dealing with the changes, which is at the heart of agility.

Now I just need someone to wave with to try out a slightly modified development flow.

I finally got out of neutral and pulled together the first public offering our Domain Driven Design courses in Cape Town, South Africa.  Normally we give these courses on-site with people on the same development team but I thought it may be fun and inspiring to open it up to everyone for a change.  Now I’m all excited again and really looking forward to a diverse mixture of people. Hopefully, I will see some old faces and lots of new people.

The one thing I can tell you is that the course is a very immersive experience.  I really hate lecturing but I enjoy probing conversations and that’s how I give the course. I don’t have answers to the practical work and concerns are addressed as we go along.  As a result, the day takes unexpected turns and routes.  But in the end I get you to the right destination.  Come along; you will leave exhausted, but inspired!

Take the Fast Track to Domain Driven Design

about the course /  course contents / should you attend? / register for the course

factor10 has expanded its services in South Africa to include our advanced and
expert level courses aimed for the software professional.  On September 8-9, 2009,
we will be offering a fast track to DDD for Architects at the BMW Pavilion in
Cape Town.

Who should attend?

This course is for software professionals that want to take the right steps towards
advanced and expert levels in their careers.  Register for this course if you want to …

• learn more than just another syntax and set of tools
• write software for large, long living systems
• increase the quality and maintainability of your design
• design high quality models and use code to represent those models effectively
• develop applications with a good APIs
• add a design edge to your skill set

Why should you learn DDD?

More and more developers and architects realise that learning every detail of a new
API just isn’t the way to deliver the best business value. It’s such a tough balancing
act; focus on the solving the business problem and focus on building working software
with your frameworks.

One way of taking a big leap in the right direction is to learn and apply domain driven
design. It is definitely not abstract and fluffy; it deals a lot with the code also. DDD
leads us to focus on understanding and to communicate that understanding very well;
in language, in design and in code. You will shift your focus away from designing for a
technology, and you will learn to design for the business domain; to the core of the
problems and solutions. Those are the most interesting parts and what your users
and customers really care about.

about the course /  course contents / should you attend? / register for the course

I am revisiting the material for the factor10 Domain Driven Design course as part of a “freshen up” for the when I give it to a development team on July 1, 2009.  So I started hunting for some quotes to liven it up a bit.

Here are some choice bites for ubiquitous language.

“They have been at a great feast of languages and stolen the scraps” – William Shakespear

and

“Thought is the blossom; language the bud; action the fruit behind it” — Ralph Waldo Emerson

And on the need for simplicity, I really liked this one.

“There is never any justification for things being complex when they could be simple” – Edward de Bono

Robert Bravery commented on an old blog post of mine and I re-discovered this one

“Don’t indulge in any unnecessary, sophisticated moves.  You’ll get clobbered if you do” – Bruce Lee

Lastly, and the one I’m definitely going to use to stress the importance of working directly with the domain expert.

“Never hold discussions with the monkey when the organ grinder is in the room” – Winston Churchill

What a diverse group of people but such collective value.  Do you have any classic quotes?  Obscure quotes?

Many big vendors have invested a lot on blue print or reference architectures.  I came across another in recent months.  I witnessed a vendor team moving from client to client implementing this reference architecture as part of their SOA solution.

What were they actually doing? They were mapping the client’s domain to the reference architecture domain and thereby identified reference architecture services that supported the client’s needs.  This most probably works for some people.   But I feel uncomfortable with it because…

• It means translating from one domain to another and back again.  It’s like having one massive bounded context around the reference architecture with a gigantic set of adaptors and transformers.
• There is a very real possibility of semantic impedance on the boundary of the two domains.
• There is likely to be two domain vocabularies or one large polluted vocabulary with synonyms, etc.

There are other reasons but these few are just old problems and habits coming back again.  Things that we accepted as dangerous and limits success in creating good software.

So, are reference architectures bad? Yes and no.  Maybe you should consider adopting its domain vocabulary as a first step.  A reference architecture with a rich metamodel is more likely to be more valuable than one without a metamodel.

And the moment you start thinking at a meta level, then you’re moving into a higher level of abstraction.  In this higher level, you will have a greater opportunity to describe your intentions agnostic of the reference architecture and the vendor’s technology stack.

The way I see it, services are defined at a meta level.  They describe your intentions and are independent of a reference architecture.  However, if you chose a reference architecture up front, then describe your intentions in the vocabulary of the reference architecture.

Does this make sense?  Because I’m just hypothesising here.

I was talking SOA – again! I was arguing that modeling of services in UML, BPEL, and any other fancy acronym immediately constrains you to a specific implementation.  For example, UML means that your are thinking OO already, BPEL means that your are thinking business processes already.  But are those (and others) the best ways to model or represent a service?

In SOA, I have a suspicion (as yet untested!) that a service is closer to an intention than anything else that I can think of because it describes the latent value of the business that invariably is lost by SOA implementations and product stacks.  Now that leaves us with a problem – how do you describe intentions consistently across any domain?   I don’t know how to do this because to describe intentions in a domain, you need to understand the vocabulary of the domain.  Until we can represent vocabularies then only can we create a metamodel for these business intentions.

So how do we model intentions in a single domain since I cannot use UML (implementation!), XPDL (implementation!), BPEL (implementation!) etc?  Since the domain is constrained by its vocabulary, we need to create a language that uses this vocabulary.  And that, my dear folks, is nothing but a DSL.  If we, therefore, model intentions (the services) with a DSL, then we are in a position to translate or transform that intention into any implementation that we like.  Realistically, we will likely need additional metadata surrounding the intention described in the DSL to satisfy UML, XPDL, BPEL, WSDL, RESTful APIs, etc.

When we think of the business as what they intend to do or achieve, then we are actually working at a higher level of abstraction – at a meta-level.  That is hard to do, but if you do it reasonably well, then you have more freedom when it comes to implementation.

SOA is so screwed up at the moment and most are climbing into or out of rabbit holes because the business intentions are being ignored or forgotten far too early or thought about far too late.  Perhaps the most effective SOA implementations will be realised with a suite of DSL’s and the only toolset that you really need is a language workbench and some very skilled language oriented programmers.