So far, a simple layered architecture has been sufficient for the shopping list application. According to the ‘minimum viable architecture’ principle, the design is fine as-is.
However, I want to discuss architecture. For discussion, I’ll introduce some complexity to the problem to motivate a change to the architecture.
So far, the shopping list can add and remove items from a single list. Now, I will evolve it into a collaboration tool for teams to shop together (e.g., in an office where everyone on a team can add to the list or buy items from the list).
In particular, I’d like the shopping list to support the following features:
- Item management
-
-
Users can buy items and then record those items as purchased
-
Users can delete items
-
Users can identify items that they’re currently buying (so that the items don’t get deleted, or purchased twice, while they’re out shopping)
-
- Integration with other systems
-
-
Adding or deleting an item will send a notification email to the team
-
Icons are automatically created for known list items (e.g., adding a chocolate bar causes a chocolate bar image to appear)
-
The system generates an expense in the office’s expense management system when an item is purchased
-
A simple implementation of these new features is in this workbook’s git repository (chapter10_teamshoppinglist_react or chapter10_teamshoppinglist_angular).
For clarity, I have simplified the integration logic: console.log replaces a real email; the expense management system is assumed to read files in a directory; and the icon generation logic only supports a small handful of items.
The point of the code is not to discuss the internals of email sending or icon generation. Instead, it is a baseline implementation to discuss how to improve the application’s architecture.
A catalog of architectures
In the remainder of this chapter, I introduce a catalog software architectures and apply them to the team shopping list.