DDD
2010-04-22 19:48
Specification by example – the missing link?
I’ve been thinking. That statement alone will be sure to put fear in the heart of a lot of you… But if you have continued on this far, here we go.
Learning programming stuff
During the last year or so I have been reading a lot. I have read stuff on XP, on good design DDD and TDD. This reading has affected me and my coding style way much more than I first thought. I simply cannot write code anymore without the test first, interface first, thinking of SOLID etc..
Learning lean stuff
At the same time I have change role at Avega. I am now an AvegaCoach. This means that my time is divided between my regular (often coaching) assignments with customers and Avega and Elevate. Since my fellow AvegaCoaches (Joakim and Christophe) and me are interested in agile and lean stuff we have focused our joint efforts on that.
This has led that I have learned a lot from them about lean and Kanban. And this has expanded my understanding of Scrum and how to work agile.
Frustrations
But around here the frustration started to kick in. I felt that these two areas; technology and process stuff could marry in a great way. But how? And how much does the it affect each other?
Also, a specific thing that I have been really frustrated in is how to include test in an agile world. Testing are left out in planning, are left to try to keep up with development and the regression stuff will eventually kill them. So “testing sprints” are introduced, “we’re running a sprint behind the rest of the team” and other solutions like that is used to try to get around it.
Surely – this cannot be the best case? So I started read about agile testing. I loved the book by Gjoko Adzic. This book introduced me to the term agile acceptance testing and specification by example.
The solution?
I have heard and learned quite a lot about BDD. I knew that BDD and “outside-in” thinking can help me design my application in a maintainable way. But BDD can be applied at any level. It could be used to spec out your unit test. Another way to do TDD (AAA becomes GWT)
But I had missed the fact that the specifications and features should could be written in collaboration with customer or business analysists. This will turn the specs into executable specifications. (Those words still gives me the shivers. It’s so cool!)
That’s the thing! With executable specifications you have a living specification to code against, and the moment you’re done (as in done done) with the story the specification is “magically” turned into an acceptance test.
And the specifications finally reflects what the code is doing. I can never forget a quote by a customer how very proudly showed me the folder with all the specifications (use cases in this case) and then told me:
“And the best thing… they are almost up to date with what the system does”.
The really scary part about that is that it was actually the best I ever seen. Most documentation and specifications are a violation to the DRY principle. But with executable specifications you’re as close as it gets.
But it doesn’t stop there: since the specification with any current tool is written in plain English you can workshop around it to get everybody's (business analysis, testing, coding, deploy etc) views on the matter. And you minimize the misconceptions by using real world examples.
And that in turn closes the gap for me; agile testing is hard since I am still viewing testing as something separate from coding. And the same goes for specifying… But it’s not! You can do this in agile way, a little slice of functionality at the time. A way to do that is specification by example.
Recommended watching and reading
Read Gojkos book – Bridging the communication gap. Stop reading whatever you reading now and start reading this. It was a eye-opener for me.
Watch (anything you can get your hands on) this webcast by Dan North. There are lots of great stuff in here on BDD and design.
I’m reading Agile Testing right now. That has really showed me that testing is something that any agile person (developer, tester, business analysist etc.) should care about. Or as Deming put it:
“Quality is everyone's responsibility.”
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
Scrum
Agile
Life of a consultant
DDD
2009-11-26 09:11
The value of an ubiquitous language
A few days back we had a mail-wise discussion on the subject; why should we care about an ubiquitous language?
For me the question falls into two parts; for the whole company/business or for the application.
- An ubiquitous language or common domain model for a complete business have never felt right with me. I know, I know; I have been defending it, striving for it and even forced it on some customers – but I don’t like it!
It will never work! The same entity, (customer) for example, can have very different meanings in different context.
A better and much more detailed discussion can be found here: - An ubiquitous language for an application is a completely different thing and is something that I think should be strived for. But that basically means that all the members of the team (customer, analysts, developers, code, tester, documentation) referrers to the same things with the same name.
For me it has to do with speed and accuracy in communication within the team.
But don’t take it for me. I did a quick search through the net and found some articles that gives better points on why an ubiquitous language is a Good Thing:
Oh yeah – thanks to Oscar and Jocke for the discussion.
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
Life of a consultant
DDD
2009-11-06 16:26
ÖreDev day #5 – afternoon
Cucumber
This will be interesting, I love the idea of Cucumber. Also the presenter, Aslak Hellesöy, has a blender on the desk… Eeeh.
He started out with a small introduction of BDD and actually TDD also. He took standpoint in the Dan North ideas on BDD, that is a outside-in approach (as apposed to the TDD outside-in), but putting the business value in the front of the sentence.
This guy is apparently the inventor of Cucumber, which has gain many followers and support in the community. It looks very well documented.
OK – the blender part wasn’t a success but it looked funny ;).
The rest of the talk was a demonstration of the basics in Cucumber and it was all really interesting. I will most certainly check this out. Although he didn’t go anywhere near .NET and C#, there was apparently support for it. And hopefully integration into Visual Studio. I don’t dare show my customer that much console-window-hacking…
ASP.NET MVC Advanced Ninja
I think I’ve seen this before… Here is a link to it. Or maybe not. No – it’s mostly new stuff done in Visual Studio 2010 and ASP.NET MVC 2.0. I’ll try to just enjoy it.
Nope – didn’t work… Here are some highlights:
- In ASP.NET 4 they have included a short hand for HTML encoding output, <%: %> instead of <%= Html.Encode(…) %>
- He also showed a T4 template that generated a static class with all the views, content, links and images. It’s still very beta, but looks promising.
- Compilation is just another level of unit testing.
- We saw how to do validation in ASP.NET MVC (2.0) with DataAnnotations. And how to use those annotations to generate client side validation. As Scott Allen did a few days ago. It’s cool!
- Html.DisplayForModel() uses templates and convention over configuration to figure out the view to generate. Cool!
- JQuery Grid looks promising.
Modeling in the age of Agility
Kevlin Henney is the name of the presenter and he seems in a hurry as all other presenters during this conference.
Why doesn’t we like to see the words modeling, architecture and agile in the same sentence. Well, modeling and architecture is kind of heavy word… Or really? That’s the standpoint that Kevlin started.
- We saw a definition of agile that simply stated that it means to do. I like that.
- “It turns out that nature knows very little about the equations we are applying to it.” – Cool quote.
- A model is an abstraction from a point of view for a purpose.
- A model is based on a particular way of framing the world of interest.
- Be discriminate when modeling – leave irrelevant stuff out. If you check a map of the London underground it’s not an actual map in a sense that the scale is not right, things are not in the right places etc.
- If you look at a pen from the end of it you only see the tip. You miss the concept of the pen. So you’ll need to flip it to show that it’s a pen. Use the right model for the domain.
- When doing a model understand WHY you do the model. What are you going to communicate? What will you present? What is important?
- Also modeling is about the –ing. That is doing modeling is more important than the produced model, because that is communication.
- He ended by recommending a great UML-modeling tool; the whiteboard! I like that also.
Final thoughts
And that’s it! ÖreDev is over. It’s been a pleasure and I don’t think I ever learned so much in so short time.
Thank you all – especially the ÖreDev-team!
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
.NET
Agile
DDD
2009-11-05 12:34
ÖreDev day #4 – morning
We’re of to a brand new day. Feel well rested although last night was quite late…
Keynote: What drives design?
This can be very interesting, if focus on the last two D in any [x]DD-technique (TDD, BDD etc). I’ll make a summary in the end.
This was a interesting historical overview to start with. Pretty cool that our industry is so young that the people who “started it all” are still not that old. Cool to hear about their troubles and stumbling on their way to greatness.
Rebecca Wirfs-Brock talked a lot about the RDD (responsibility driven design) and the patterns behind it. Then said compared it to other DD-techniques, such TDD, BDD, FDD and DDD and so forth.
Making the sausage
Now this should be interesting if by no other reason because of the speakers; Dan North, Neal Ford, Stuart Halloway and Tyler Jennings. They are going to talk about BDD in something called Clojure. It promise to be great!
It was a bit disappointing in a strange way; it’s was great but I had a hard time keeping up with their ideas. But after a while I get it but not well enough to re-loop it here. Sorry.
Functional languages are strange in itself and four functional programmers running through code they wrote a late night… You can probably understand my confusion.
Test-Driven Web UI Development
Scott Bellware is doing this. It’s the first time I’ll hear him, except in the local pub…
The talk was about lessons learned on trying to bridge the gap between testers and (TDD-)developers in an agile team.
Here are some random stuff that I picked up:
- Selenium looks like a cool UI-automation testing framework. It free!
- Selenium can actually generate test-code in a programming language of your choice. Beware that the tests are just a starting point – not the full blown test suite to use for ever and ever…
- As programmers we shouldn’t do things that decreases productivity for the testers. It’s the whole teams productivity that counts.
- The tests should describe the product not the implementation.
- Good BDD-tests should be like a Table of Contents in a book. You don’t want to go into details if not needed.
- Pair programming with a tester and a developer may be a way to find issues really quick. But I think a good, solid understanding of the test framework is needed.
I learned some about of Ruby and some on automating tests. I liked it but we didn’t reach all the way, sadly. James Bach had some comments that I would have loved to heard more around.
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
Agile
DDD
2009-10-19 11:17
Reference work #4 – Domain Driven Design by Eric Evans
I have continued down the reading path of classics in IT-literature. The time had come to read: Domain-driven design: tackling complexity in the heart of software.
I must confess I was a bit nervous on how much I would understand – many reviewers of this book often say things like; excellent but [complicated, high level, hard to grasp, boring to the end].
I disagree – I think the book was excellent and that it came together as a whole in a very nice way. I must confess though, that if I’ve never heard about DDD before I don’t think that I would have enjoyed it as much. Don’t get me wrong – it is the seminal book on the subject but I need more time to grasp subjects like this.
I’ve learned DDD backwards – starting with code and working my way back via lectures, books and articles and finally the Eric Evans book.
But the book gives a very comprehensive guidance of the subject and IS the best resource to look back to. Also it talks a bit about how the design approach will influence the way you work, with your customer instead of against.
There are numerous and lengthy examples which clarifies subjects in detail. Some of them was quite hard for me to follow but that mostly had to do with me not getting the domain and the English (ie. advanced banking and electrical circuits).
And hey, that’s the whole point, get to know the domain in order to be able to produce great software for it. My bad probably…
I’m sure I will return to this book many, many times and I have already included some ideas and patterns into my current project.
Look to this site to follow on in all things DDD, for example the sample project.
I continue my journey down great IT-literature with The Art of Agile Development, which already looks quite well read thanks to a certain relative that seems quite interested already…
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
Life of a consultant
DDD
2009-09-09 09:16
AutoMapping with FluentNHibernate
I ran across this post by Ayende and it pretty much sums up where I want to reach with my persistence ignorance efforts:
“After that, you are done. Just create an entity in the proper place, hit the /database/create and have a lot of fun.”
I of course like the fun-part of the quote the most. :) But seriously – that what I want to reach – to configure my conventions. And then simply code the model as I want it and let the framework (NHibernate in this case) figure out how to store it.
Well, as it seems, the Fluent NHibernate framework has been updated since the Ayende post. So I’ve read, and read, and read and discovered some shortcuts. By the way – here is an article on how to make the transition from the “old” convention-style into the new.
I have put together an updated sample for what Ayende did in that post above. I also added a feature to be able to automatically set cascades for OneToMany- and ManyToMany-relationships.
Here you’ll find the most important parts of the code.
[UPDATED]
Here is the complete sample.
Did I mention that I LOVE Fluent NHibernate? Well I do!
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
.NET
DDD
NHibernate
2009-08-31 14:47
Implementing Unit Of Work with NHibernate
The more I work with it the more stupid I feel around what I have been doing before; why have I written so much SQL? It feel just … unnecessary. Who said stupid? Not me…
Jimmy Nilsson said something like; “I just want the database and storage problems to be a consequence of my domain model. I don’t want to think about it”. And that is one of the goals with DDD and the solution is, for example, NHibernate.
I have been doing some labs with NHibernate the last couple. And as often with me – I think I am in love. NHibernate really rocks. The mapping files are quite hard to chew off at first and I suspect that there are many tricks and traps for me to find. But still – so beautiful.
Of course the Net has helped me a lot on my quest. Here are some articles that I’ve used:
A bit on the sad side (or NOT) is that we were trying to create a Unit Of Work implementation for NHibernate. Not only has this been done before, but also apparently NHibernate hooks into the System.TransactionScope implementation of the .NET framework. Thanks a lot to the gurus of level 3 – Magnus and Calle who show me that. All my code – down the drain… :)
OK – this has been a great learning experience. If you want the code – drop me a line and you’ll have it in a jiffy.
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
Agile
DDD
2009-05-18 19:05
DDD – what’s the deal?
After doing DDD (on a very basic level) for sometime now, I now realize that I could benefit with some sort of sum up. Often when I reach this point I quickly realize that many people has tread this paths before and that I’m reinventing the wheel…
Well, in that case I do it for me. I like my wheels or at least my way of understanding them…
So here is my take on what the deal with DDD is (i hope that it will change over time but here is how I see it today):
I think first that the whole idea of DDD can be divided into two aspects (actually Jocke pointed me in this way but i like it):
- first code - a bunch of design patterns that help you produce great object-oriented, testable software
- then the implications on the way you can do software projects.
For the code part there is not much to add, or rather not much that could fit here. But what I mean is that to do DDD is “simply” to apply the patterns Domain Model, repository, aggregate, services, factories and more.
It can be quite a challenge to grasp all these patterns and put them into use at once, so I recommend a some reading, that will set your mind into DDD-mode and most of the patterns will fall into place by themselves. Or you can grab hold of an example architecture and build from that.
The other part of the story is the way that setting your brain into DDD-mode will change the way you can be agile in your project. The main idea (as I founded out, and here) is of course to focus on the model and let implementation details such as database integration, technology or even GUI be of secondary importance. Of course you cannot take in the complete universe of your problem at once so doing a small part of it and letting that evolve with time is a recommended approach. See this from Jimmy Nilsson.
This approach lend itself very well to do in the form of for example user stories and TDD. In this way you only need to focus on the part of the model that the user story is about. The next user story might tell us more about the same part of the domain model, but we don’t care now. The tests will assure us that we’re not breaking anything that already works as we progress.
So by doing DDD you automatically get a step-by-step evolving architecture and also a very good way to use an agile approach in the project.
With BDD (a subject I know very little about) you can even go further and get specifications that you verify with tests. But that is out of knowledge.
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
DDD
2009-05-18 18:35
S#arp Architecture
In a previous post I briefly referred to Sharp Architecture (what’s the thing with the funky spelling?).
I have now read a bit about it and I must push for it harder. It’s rock good! What an ambitious project!
The idea is to give you a boiler-plate architecture that contains best practices and useable functionality when doing DDD, TDD, ASP.NET MVC and NHibernate.
You know – the way you always feel when a project is done… “This is so good that it easily could be a framework, if only …” – These guys has done it for you.
It’s not done and still have a bit to go before but I really like it.
Check it out. Here are some introduction videos:
Postad av Marcus Hammarberg
Kommentarer (1)
Kategorier:
.NET
TDD
DDD
2009-03-03 22:03
Sprint Planner Helper – a DDD learning experience
Since about a month I am on parental leave (föräldraledig in Swedish, not sure on the translation) and I am loving it.
However when I left for that leave it was a lot of things that caught my attention, such as doing TDD for real, DDD and ASP.NET MVC, and I felt that I needed to do something that had with my profession to do…
So I pondered that for a while and came up with a project that could keep me busy on a comfortable level (have fun, max 1h/day or 5 a week are my rules). The project name was Sprint Planner Helper
I have been blogging about this on my private blog, www.marcusoft.net , but have now decided to post to the Avega-blog also. To not go into post-mania and repost all my current posts here, you get a link list instead:
Oh my God – I hope no-one reads all of them at once…
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
TDD
Sprint Planner Helper
DDD