Using anti-requirements to find system boundaries
We all love building greenfield projects. 1 But inevitably, starting a new project involves lots of meetings with business stakeholders to hash out initial requirements and canonical data models. Those are…not so fun.
When one of those meetings occurs after a carb-heavy lunch, it’s easy for your mind to drift away…back to those university lectures about entity design. Think of the nouns and what attributes they have. A dog and a cat are both animals and have 4 legs. Except now it’s Customers, Orders, Products, and Shopping Carts.
Is this the best way to build a system, though? Didn’t we do the exact same thing on the previous greenfield project we’re now rewriting? Surely we won’t make all the same mistakes we made last time…right?
Read moreOr a rewrite of the greenfield project from 5 years ago, but that's another story.
We'll know the project has hit the big time when we can no longer make the diagram fit on one page and remain readable. That's OK. I hear the copy shop down the street has a large format printer we can use…
Spoiler alert: sometimes, these inventory numbers are totally fake and designed to scam you into feeling more pressure to buy! In other cases, you can continue to sell even when there's negative inventory by putting an item on backorder and notifying the customer when it becomes available. Here, let's pretend that we need this inventory to be accurate, at least as much as eventual consistency will allow.
Anti-requirements or antirequirements, with or without the dash. Or, you can call them de-requirements or even dequirements? We'll stick with anti-requirements in this post.
For another example of this kind of decomposition, check out Putting your events on a diet.
You don't always have to ask them about anti-requirements directly. Using anti-requirements as a mental device on your own is just as valuable.
Never ever had so much fun with a thesaurus. 😉
Be careful with this anti-requirement too. In some contexts, inventory and shipping time could be related if a predictive algorithm determines that items with low inventory are likely to oversell, which means we can't promise 24-hour delivery. As always, it depends, so ask the business stakeholders to be absolutely sure.
Harvard Business Review says the [most productive meetings have fewer than 8 people] because the number of people attending tends to have an inverse relationship with meeting productivity. And honestly, even 8 feels like a lot if you want to accomplish anything!
Both terms have been abused so much they're almost meaningless, so take your pick.
In vertical slice architecture, each service is responsible for all of the traditional "layers" (i.e., UI, Application, Domain Logic, and Database) within the slice that can be defined, in part, using anti-requirements. Check out videos on vertical slice architecture by Jimmy Bogard or Derek Comartin for more.
This video uses the same shopping cart example as this article. Remember that the ViewModel composition code shown in the video is already out-of-date. Using ServiceComposer is a lot more user-friendly.
