Published on 02 August 2014 by @mathiasverraes
Have a look at these two classes:
Would you say this is duplicate code? Does it violate the DRY principle (aka “Don’t Repeat Yourself”)?
If it is, then the solution to get rid of it, could be something like this:
The code is identical, but why? As good Domain-Driven Design practitioners, we’d have to check with the business. The product could be a flammable chemical, and for safety concerns, a shipment is not allowed to have more than three of them. As a consequence, we don’t allow customers to order more than three at a time.
In another scenario, the similarity of the code might also be simple coincidence. Maybe supply of the product is limited, and we want to give our customers equal opportunity to buy it.
Whatever the case, it doesn’t matter. The problem is that the rules might change independently. The business might realize that they can still sell more than three products at a time, and divide the products over multiple shipments. In example 2, we are now stuck with high coupling of both types of domain objects, to the same business rule, and indirectly to each other. Changing the rule for Basket, changes the rule for Shipment, but potentially has dangerous consequences in the real world. The example is of course blatantly simple to refactor, but legacy code is usually a lot harder.
You might be tempted to solve the problem by abstracting the limit:
This works to certain extent, but the rules might change in unexpected ways. Example 3 assumes that the limit is always easy to determine with a single method call. New rules might take into account the customer, their history with our company, certain legal conditions, promotions, etc. The new rules can dynamically influence the number of products you can buy, in ways that can’t be modelled using our abstract
The business rule in my example is not “Max 3 products allowed”. There are in fact two business rules: “A basket is not allowed to have more than three products” and “A shipment is not allowed to have more than three products”. Two rules, no matter how similar, should have two individual representations in the model.
“Don’t Repeat Yourself” was never about code. It’s about knowledge. It’s about cohesion. If two pieces of code represent the exact same knowledge, they will always change together. Having to change them both is risky: you might forget one of them. On the other hand, if two identical pieces of code represent different knowledge, they will change independently. De-duplicating them introduces risk, because changing the knowledge for one object, might accidentally change it for the other object.
Looking at the reasons for change, is a very powerful modelling heuristic.
Follow up posts:
Some posts about Domain-Driven Design:
Follow @mathiasverraes on Twitter.
|Introduction to Event Storming||CukeUp||Workshop||London, UK||April 14-15|
|CQRS/EventSourcing + EventStorming||NCrafts||Workshop||Paris, FR||May 11|
|TBD||NCrafts||Talk||Paris, FR||May 12-13|
|Experiencing Domain-Driven Design||Value Object Comm.V||Workshop||Berlin, DE||July 6-8|
|Tactical Domain-Driven Design||Laracon EU||Workshop||Amsterdam, NL||Aug|
|Experiencing Domain-Driven Design||Value Object Comm.V||Workshop||Amsterdam, NL||Sep 7-9|
|TBD||TYPO3 Developer Days||Talk||Nürnberg, DE||Sep|
This work by Mathias Verraes is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 License.