Hello peers in wisdom,
I hope you had a wonderful week. Todays topic consist on exercising a non technical part of software.
Domain-Driven Design
DDD is a set of tools that makes easier to understand business experts and then translate their knowledge domain to our domain (software). I encourage you to learn more by reading and watching the resources I found useful, they are at the bottom of the post.
Pricing goods
The definition of the problem is on this kata. The goal, basically, is think about functionalities, edge cases and implementation for pricing goods at a supermarket.
Steps I followed
Event Storming. This method helped me to start defining what where the things I expected to happen in this system. In the image you can identify them by the salmon color. Its important to note that at the bottom right is defined the meaning of each box color.
Commands and actors. The next step was to ask who makes what. In this case I assume the pricing decision was made by the procurement department. These are the blue and green boxes.
Policies and hotspots. In this case policies are the conditions that need to accomplish to proceed with the events. The information that this policies validate comes from the query models.
Query models and external systems. Query models are an abstraction that allows us to receive information from external systems. In this way external systems might change but our code does not. I though hypothetical external services such market studios, reports and government communicates that may retrieve information through an API to our system. External systems makes procurement department take the decisions of changing prices, applying discounts or removing products.
Tactical design
On the right side of the diagram I defined what the aggregate, entities and value objects will be.
And finally an answer for some cases of kata01:
Case 1. How system can handle different kinds of discounts (2x1, 3x2, -10%)?
In my solution I managed it by creating a discount value object that implements different rules for each kind of discount.
Case 2. How price different kind of products that are measure different (kg, pieces, liters, gallons)?
The entity product has an attribute measure_unit, which allow us to chose what prices refers to.
Case 3. Is and audit change price needed?
I think is an important feature and not only for price also for discount. This will allow us to make use them for training an AI to automatize or at least suggest us when to change them.
Case 4. When rounding take place?
The lowest money unit is a cent, and there can be multiple escenarios where its not enough and therefore is necessary to round:
1. Make a percentage discount which result has more than 3 float points (0,8777)
2. The unit is not discretion so for example buying 2.333 kg of rice will cost 2.3645 dollars.
3. The same case with discount but for taxes
Case 5. if a shelf of 100 cans is priced using “buy two, get one free”, how do you value the stock?
The stock is value with 67 cans since the last pair its not enough to apply the discount. Also there is the possibility of not every client makes worth the discount, in that case the value of the stock will increase.
Conclusion
This activity is great to develop our business logic part which often is weaker than the technical part.
-Alan
Resources I found useful
DDD Resources - Domain Language
Introducing EventStorming - EventStorming
Domain-Driven Design: The Last Explanation You'll Ever Need


Comentarios
Publicar un comentario