This blog post will elaborate on the most important part of a good software system: the domain model. As everybody knows business software is for IT alignment making sure that the organizational processes are optimally supported by a system. This can only be done if the data in the system is correct and represents the domain objects in a good way.
Domain model
The domain model is a definition of all the objects that exists in a certain area. It describes in an untechnical way which relations and which attributes these objects have. Further it can contain some constraints on objects e.g. a bike has two tiers and a car has four tiers.
The oldest technique to create a domain model is a glossary. Every scientific book has one and every software system should have something similar as well.
Good definitions will make your software less complex, your communication more efficient and in the end more usable.
Domain modeling
It doesn’t matter which project methodology you prefer cowboy coding, waterfall, Kanban, or Scrum all contain the part that you have to model the domain. Doing this tasks always involves to get some domain knowledge.
Easiest way is to talk to domain experts and collaborate with them to create the domain model. One important thing is to teach the domain expert the modeling language that you will use. We at incentergy use UML class models but you can use anything. Here is a short list for modeling languages:
Most of the time even for the domain expert it is not always obvious how to model the data e.g. is an email address a 1-to-1 relationship to a person?
If you think about it you will recognize that a person can have multiple email address further it can happen that a whole household shares an email address so after some discussion you might come up with an n-to-m relationship
Data types
There are technical data types for attributes e.g. string, blob, integer, float, or double and there are business data types like string, person, currency, or time. Some data types exists in both worlds. Nevertheless the technical type is most of the time a lot better defined than the business one.
Here is a small table about some data types and one definition for them. I would recommend to always use an international standard:
| Name | Standard |
|---|---|
| Datetime | ISO-8601-1 |
| Float | IEEE-754 |
| String | UTF-8 |
| Currency | ISO 4271 |
| Country | ISO-3166 |
| Unit | UN Rec. No 20 |
These datatypes should be explained to the domain experts. Further you should elaborate what the standards actually mean. Often it is the case that technical persons are doing business settings and they do it wrong e.g. setting up VAT rules. Engineers and business persons have to work together. Best would be both in front of the same computer.
Business rules
If you have a good domain model it is easy to define business rules. Actually there is even a whole programing paradigm based on knowledge definition also known as fact and rules. The most basic language is prolog.
A lot of people are currently inventing domain specific languages for certain business domains but these DSLs make only sense if a good domain model is available. So in our domain online marketing we often are asked to make special promotions for special cases. If you have a good domain model these promotions are readable by business people e.g.:
if(month(now) == december
&& basket.products.length > 5) {basket.createDiscount(percent(10));
}
Another example would be something like:
if(basket.contains(alcohol)
&& basket.buyer.age <18) {basket.showError(“You are too young to buy alcohol”);
}
You can make both code work in JavaScript or Java. Further this is understable by the domain expert and with a lot of examples the domain expert might even be able to write their own rules.
Martin Fowler writes multiple articles about DSL and business involvement.
Communication
In a project communication is key. A project manager should use everything that support him with communication. For project management controlled and formal communication is a key to success.
A shared space for documents and a project handbook for keeping meeting minutes and write down taken decisions helps a lot to run the project smoothly.
Changeability
Everything should be always changeable without creating inconsistency. Normal operations are introducing new entities, renaming old once etc.
It happens quite often that in the code a certain entity has another name then on the UI. When changing something then all components and documents should be refactored to have a consistent naming afterwards.
Our incentergy software uses model driven architecture to make sure that everything is always consistent. If you want to use similar sophisticated methods please contact us for a quote.