It took us over a year to implement this application for a company in oil&gas sector. Customer seems happy, we are happy – let’s call it a success. It was Silverlight 4 front-end connecting to WCF services in the back-end. We have encountered quite a few technological challenges but the biggest challenge was the domain that none of us has ever worked with.
We had to learn a lot about licences, bidding, drilling, platform development, oil production, pipelines, gas contracts, taxation regimes, accounting, corporate finance… I could continue for a while, but the bottom line is that it is complex stuff. Now after a year I can say that the model we have built is not perfect and I would gladly rewrite some parts but overall I think we did pretty well.
Whenever anyone says Domain Model everyone thinks of DDD. I cannot say we have followed DDD by the (blue) book, but lets say we were inspired by the ideas.
Ubiquitous language and knowledge crunching
This part worked really well. The scope of the application and complexity of the domain made it hard to just explain (or rather understand) how it all should work. To get us started we would talk to the customer in a room with a whiteboard and draw UML-like diagrams trying to illustrate a story told by an expert. BTW - we were lucky - the customer was a real expert (infinite source of domain knowledge). We initially wanted to redraw the UMLs using a computer tool, but we only ended up taking pictures. At the end we have not even used the pictures too much. The diagrams were just very helpful to organize the information as we received it. They allowed us to create high level mental models of the domain and learn the vocabulary used by the experts.
An interesting bit is that we ourselves have created a lot of concepts that the experts found useful when describing the functionality. In some cases they were just names for things they don’t even care to name. In other cases we needed more precise names to avoid ambiguity. When creating new concepts be very careful. If an expert feels the concept is artificial and the word does not describe anything they are familiar with, it is probably not what you were looking for.
Most of the concepts we put in the diagrams ended up as C# classes. We have created many classes we have not anticipated when drawing the diagrams, but the high-level structure of classes was pretty close to what we discussed with the customer. Of course we did not get it right the first time and had to change the structure many times as we discussed new features. The good thing was that when discussing changes we all used the words that meant the same thing to the expert and us – developers.
Now you may wonder if it is possible to teach the customer enough UML to be able to use it as a communication tool. My experience shows that in most cases it is. At the end, you will need a smart person as an expert to be able to learn from them. If they are smart, they will understand that a rectangle with a name represents a concept. Then use a few examples like Pet, Dog, Cat or Vehicle, Car, Bus to illustrate generalization and specialization. Associations are also easy to explain (Car “has” wheels, Pet “has” Owner, etc). Just don’t try to explain composition vs. aggregation. A simple arrow is enough at the level of details you want to capture at this stage.
End of part 1
In the next parts (if I ever write them) I want tell you about:
- why Analysis Patterns is a book worth reading,
- why the customer was suppressed they will not need SQL Server licence,
- why you need to be very careful when deciding to use State design pattern
- why contracts are the best thing since sliced bread
No comments:
Post a Comment