One of the good things that I picked up during my short but eventfully learning stint at Simpl was how long a well thought about domain data model can go. The one that I couldn’t for my life, was tests.

Jokes aside, this has been one healthy learning that has taken a while now to put into some practice. Yes, we did have something that nominally resembled this at crisp, but the constraints did prevent us from going all in.

But, the recent experiment with converting Plum’s order system to an event driven architecture came in handy as a test bed for the learnings. It in earnest started with a revamp of our internal dashboards with a two fold approach.

The first being a purely data(base|schema) driven approach to APIs and the source dictating constraints and responses. This does take away a lot of flexibility from the developers at some point, but certain environments mandate this lack. The second addition here was a rehash of my earlier work of reflected data classes where the defined schemas generate classes - an app stack level representation of ER?

One of the pain points here was the fact that a majority of the current tables that we work with have not been built on top of referential integrity and constraints but have application stack handling it for long enough. This migration might be a solid exercise for another day, assuming we have sanity to.

Getting back, the other change while scaffolding the event driven system was to clearly separate out concerns. The controllers as they were doing nothing beyond routing to the data layer and the data layer handling both data sourcing and any business logic.

Where this stands, this does warrant some more polishing around a few rough edges - the flexibility to switch data sources is still an effort given it is coupled with business logic. But the exercise in all, has opened up a few paths to improve the current system and make it more auditable across.