That makes it our job as developers and architects to dig for it. They’re generally surprised that developers don’t know it already. Since business domain experts tend to think of this stuff as obvious, which makes them unlikely to volunteer this information.
Without anti-requirements, teasing out these details can be tricky. When they laugh at you, that’s a hint that although those two attributes are verbally associated with the same noun, there isn’t any meaningful logical relationship between them. “If the product has more than 20 characters in its name,” you say to them, “then its price must be at least $20.” 5Īnti-requirements are deceptively simple: you create some fake requirement concerning two attributes and present it to business stakeholders. Using anti-requirements is a powerful way to increase autonomy by breaking your domain into separate islands that can evolve independently. To help decompose a complex domain, we can use anti-requirements 4 to find attributes incorrectly lumped together on the same entity. What happened? And, more importantly, how can we fix it? 🔗Anti-requirements to the rescue The sinking feeling of déjà vu from the old project starts to creep in. Our Cart object no longer looks like a proper DDD aggregate, with everything dependent upon everything else and data being copied everywhere. So now our shopping cart starts to look a lot messier, and we’re starting to get worried thinking about all the batch jobs we’ll need to write to keep this thing updated. At least the marketing folks insist that changes to product names and descriptions should be infrequent and primarily limited to typos. So every time any of these values change, they’ll also need to be copied from their source of truth to any shopping cart with a matching item.
As it turns out, we discover similar concerns around delivery estimates, item names, and descriptions. For example, you might need the data to be denormalized for performance, or the warehouse data might exist on a physically different system that can’t participate in a database join. You may be able to join tables to get this information, but that’s not always an option.
THE NOUN PROJECT BUSINESS LOCATED UPDATE
To keep this value up-to-date, every time the inventory of any item changes in the warehouse, we would need to check every active shopping cart for an instance of that item and update its value. The business intends to use this to pressure customers to purchase before it’s gone. Next, we realize that we need the inventory level to accurately reflect the available inventory in the warehouse. So now the cart items need to store the current price and the previous price, and we have to do a lot of copying whenever any related data changes. However, if the price of an item goes up, we need to warn the user about it and make them accept the new price. So whenever a price changes, we must copy that value to any shopping cart containing that item. So we’re now combining data and behavior together…this is essentially an aggregate which means now we’re doing domain-driven design! 🔗More attributes, more problemsĭuring development, we start to see some flaws in the plan.įirst, we learn that if the price of an item goes down, the new lower price should also be reflected in the shopping cart. We’ve also realized that a cart has some behavior associated with it as well, operations like AddToCart(), SaveForLater(), and Checkout().
THE NOUN PROJECT BUSINESS LOCATED SOFTWARE
Here’s the shopping cart part of the entity relationship diagram we’ll print out and keep at our desk 2 like a holy article of software design scripture:
ShoppingCart is a noun, after all, and it’s got a list of items in it, each of which has simple attributes like Price and Quantity. 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? 🔗One cart to rule them allĪs the meeting continues, the design for the shopping cart begins to take shape. Except now it’s Customers, Orders, Products, and Shopping Carts. A dog and a cat are both animals and have 4 legs. Think of the nouns and what attributes they have. 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. 1 But inevitably, starting a new project involves lots of meetings with business stakeholders to hash out initial requirements and canonical data models. We all love building greenfield projects.
0 kommentar(er)
