Architecture Kata "Share DVDs"

Develop a software system that allows DVD owners to share their treasures with others. The motto: Why buy a DVD when you can have it given to you? [1]

DVDs enter the system via their original owners. However, they do not remain there. Instead, they circulate among the users of the system. Anyone who borrows a DVD does not send it back to the person from whom they borrowed it. Instead, they keep them until someone else wants them. In this respect, you could say that it's not about lending, but about giving.

There are several copies of each DVD title in the system. These are distributed across several users. If a user wants to watch a DVD, they search for a suitable title in the catalog. Once they have found what they are looking for, they order it - but the system selects the specific provider. [2]

The supplier is notified of the order by email. He then sends the DVD to the customer and notes this in the system. [3] As soon as the customer has received the DVD, this is also noted in the system.

While the DVD is in the post, it can of course not be ordered again. The number of copies of the title is reduced. This also applies during the exclusive usage period after receipt of the DVD, which can be 14 days, for example.

If everything goes smoothly, the system is simple:

  1. Owner adds DVD to the system and becomes the first provider. The catalog grows by titles and copies. [4]
  2. Interested parties browse through the catalog and order a title.
  3. The system informs the provider who is to send the shipment.
  4. The supplier sends and registers this in the system - which informs the customer.
  5. The customer receives and acknowledges.
  6. At the end of the exclusive period of use, the purchaser automatically becomes the provider - or the purchaser offers the copy again beforehand.

However, not everything always runs smoothly, even if everyone involved is of good will. A lot can happen:

  • The provider does not send the DVD (because he has not seen or received the notification or forgets to do so).
  • The provider sends, but does not note this in the system.
  • The customer does not receive the DVD because it is lost in the post. This case cannot (initially) be distinguished from the case where the provider does not send the DVD.
  • The DVD reaches the customer in unusable quality. The cause may lie with the postal service or the supplier - it may be difficult to distinguish between the two cases.
  • The customer does not acknowledge receipt.

The system must help to recognize and compensate for these cases. For example, a supplier can be automatically reminded by email to send an ordered DVD if he has not noted this within a certain time. The customer can be asked by email whether they have received an order and asked to inform the system of this.

Beyond such reminders, however, it must also be possible to make copies of [5] from the catalog because they are unusable or lost. This can be done automatically if the customer's receipt is not received long enough. However, this can also be done manually if the DVD is unusable. [6]

To ensure quality and build trust, the system must of course also enable ratings and create transparency. Users log in with their full name, email, password and delivery address, otherwise delivery cannot be made.

Anyone can view everyone's activity statistics:

  • Number of copy registrations
  • Number of orders
  • Number of unsuccessful orders
  • Number of unusable copies in relation to its orders
  • Number of shipments
  • Number of unsuccessful dispatches
  • Number of unusable copies in relation to its shipments

Transparency creates trust. For this reason, an explicit evaluation system should initially be avoided. Instead, the statistics can perhaps be condensed into a rating.

However, as long as the provider who is to fulfill an order is selected by the system, transparency is of limited value to users. After all, they have no choice. However, the system can use such data to block users after a prior warning. [7]

DVD titles can be registered by entering an Amazon link (or just the ASIN). The system then retrieves all the essential data from there and refers to Amazon for the rest. Additional copies of a title can of course also be registered via the catalog.

The user profile also includes an overview of orders and shipments as well as an inventory overview. [8]

Worth considering:

How can a user exit the system? Can they simply log out at any time and remove the copies in their collection from the system? If the system is based on giving away instead of lending, i.e. if every order represents a change of ownership, then leaving the system should not be a problem.

Of course, this can also lead to abuse. A user can order many DVDs and then simply opt out. In this way, he would only get a personal collection by investing in postage costs.

But maybe that's not such a bad thing. After all, the original owner's wish when registering his copy was to "get rid" of the DVD without throwing it away. This wish has been fulfilled - and there is always a chance that the copy will be enjoyed by many users before it ends up in a "black hole".


[1] Keyword: Collaborative Consumption

[2] There can be different algorithms. The simplest is to simply take the first provider in the list of providers of a DVD. But it could also be the one that has stored the title the longest. Or the one that has stored the most titles.

[3] Whether the postage is paid by the sender or recipient is probably not important for the implementation. However, for such a system to be attractive and fair, it would probably be advisable to use freight collect shipping.

[4] Consideration should be given to how DVD titles can be uniquely identified. Is there such a thing as an ISBN? Or could the Amazon ASIN be used? An entry there could also be referenced for details of the DVD.

[5] Copies must therefore be given an ID upon registration. Is there a serial number for DVDs that can be used for this? Or must an ID be generated by the system, which is then noted on the DVD? Or is the combination of title ID plus email address of the current provider a "floating ID", so to speak?

[6] With "floating ID", the ID of a copy only changes once the customer has acknowledged receipt and assessed the quality of the copy as usable.

[7] The automatic selection of the sender could also only be a temporary solution until a critical mass of movements has taken place in the system in order to provide meaningful figures. In this case, however, a brief evaluation of the shipper by the customer should be possible after receipt.

[8] The system could also periodically call for an inventory, in which each user checks their stock and reports any differences. Perhaps a DVD that has not been ordered for some time has gone missing.

en_USEnglish