I will be running a 6 hour long session at the Scrum Gathering in Cape Town in September titled Modeling Out Loud. I’m now convinced that the Scrum tribe are weird. They call these sessions Deep Dives. Presumably, you need to carry enough oxygen to survive the session.
I think I’m going out on limb here because I will be challenging the value of Product Owners writing stories. I’m also suggesting that when Product Owners write stories riddled with behavior then developers are disconnected from domain experts and you regress into a waterfall mode of execution fronted by a Scrum Board. So be prepared to experiment with me and turn up your self-reflection to maximum level because we will challenge many assumptions.
Tag Archives: Ubiquitous Language
Fast Track to Domain Driven Design
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
Great Quotes for Domain Driven Design
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?
Domain Specific Reference Architectures
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.
Services are Intentions
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.
Who are you targeting with your DSL?
I had quick DSL appropriateness argument last week for someone that was objecting about us implementing a DSL for some small part of the domain.
The argument: “Business users will never write code”.
My response: “But business users will read code”.
And to test the argument, I later emailed one of the business users with a small snippet of the DSL that we were crafting and simply said in the email: “Please check the following configurations for the client…”.
His response: “You incorrectly configured the final_costing_policy. It should be …”
In the large, the DSLs that you create are going to be read by a larger audience than just developers. So, like all good code, this DSL code should be highly readable, but not all of your audience needs to know it’s syntax in detail. You create a DSL to make your life, the developer, easier. Getting business users to understand what you are doing is part of making your life easier. Anyway, is it not about ubiquitous language and vocabulary? You can’t get closer to the domain than revealing data and behavior with a DSL, can you!?
Discovering Language and Context
Last night, I attended the 43rd Cape Town SPIN meeting that turned out to be a fun, interactive exercise with John Gloor. John introduced a system of analysis which focused on modeling a domain – but not from and object oriented paradigm. It was more about “things” and “influences”. I am really doing a bad job of using the right terms, but let’s just try something out.
- As a group define (frame?) your problem domain (We chose “How to be a successful team”)
- Then individually…
-
- write down as many thoughts about the domain as possible – short snippets of 3-8 words each. The recommendation was to aim for about 70 thoughts.
- Color code (or group) these based on some notion of similarity.
- Give each group a name or label on a post-it
- Then as a group …
-
- the first person sticks their post-its on the wall
- each other person, in turn, then sticks their post-its up and aligns it with whatever else is already on the board (or creates a new spot altogether)
- Optimize the emerging clusters and give them names
- Finally, put directed lines between the named clusters using the guide of “A influences B” and give the line a label as well.
We never had the time to get to complete step 6. But the really interesting angle for me was that a language for the domain was emerging. It was not perfect, but it was a nice start. Secondly, some of the clusters felt a lot like strategic contexts. Sure, it was a conceptual decomposition of sorts, but it may well be a nice starting point for discovering bounded contexts.
And those influence lines felt like dependencies and interactions between contexts. The use of the word “influence” is a really nice alternative to the traditionally naive terms like “uses”, “has”, “is like”. It naturally focuses on behavioural interactions.
So, this simple exercise may be a nice technique for discovering language and contexts within a domain. And it proves to me, yet again, that language is most critical. This is not just about maintaining a lifeless glossary of terms – but the energy surrounding the vocabulary and terms need to be depicted and felt as well. And if we combine all of this with an agile mindset, we can adjust this “language model” with each iteration and gain deeper domain understanding continuously. Hmmm, this notion of “language model” is intriguing!
Flowing in the Waves
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.
Modeling out Loud Deep Dive
For those of you that attended the Modeling out Loud deep dive at the S.Africa Scrum Gathering today, here are some things that I discussed. It’s in no particular order, and it only makes sense if you attended the session.
- BDD Stories that are authored outside the team contributes to a hand-off which influences design decisions.
- Because we understand something does not mean that we know how to design it.
- Be aware of when you are analysing and when you are designing.
- Be concrete and abstract late.
- Use the scenarios to close the loop with product owners, stake holders, etc.
- Developers should write BDD stories and scenarios.
- We are less ignorant at the end of the sprint than at the beginning.
- Use code to close the feedback loop for your story.
- A story and it’s scenarios can be a representation of your model, just like a picture, UML, test code, production code.
- Seek out the behavior and express intentions.
- Use the value statement to explore alternative needs.
- Product owners should not write BDD stories
- Recycle stories if there are scenarios that you cannot commit to.
- Keep out the technical jargon. The moment you get technical, then the story shifts to an implementation.
- Evolve and accept that it is ok to change … your story, your scenario, code, anything.
- Login is not a story
There was a lot more which we all discussed, so feel free to add what you got out of it as a comment for others to grab.
The slide deck which contained the code example is available at http://bit.ly/bhNkvQ.
And lastly, thanks for joining in. I sincerely appreciate you making the time.
Remember that writing stories is a really difficult thing to learn, because is design is hard. Persevere.
f3yourmind 