Part of my current job is supporting requirement engineers during design stage. However, I am supposed to support engineers from my team and each team has their own solution architect. This week, however, another team’s requirements engineers have come to my desk and asked for support.
They were working on lice-cycle of an important business object and wanted to design it with clean and elegant implementation in mind. They’ve been considering two major approaches to marking that business object as having reached a given stage in its life-cycle:
- flags in entities representing certain conditions being met (so when a business event takes place, appropriate flag is set);
- states, of which there would be potentially quite a lot and the resulting state diagram would be very complex.
It turned out that their team’s solution architect did not get involved in discussions like that and so they came to me. For me, solving design problems is one of the most satisfying activities, so I’ve jumped in right away.
In the end, I’ve suggested using Event Sourcing for the following reasons:
- they need to support auditing, so tracking business objects’ properties along their life-cycle is a must;
- from my perspective, what they’ve been trying to represent as flags or states, could as well be represented as events. In fact, they are business events.
It’s been very rewarding and I’m looking forward for some more design problems to solve!