Workshop - The Little Pattern That Could.pdf
- 1. The Little Pattern That Could Leveraging the Power of Repositories Tobias Goeschel Sr Solutions Architect, FSI Amazon Web Services
- 2. Before we start: A disclaimer To teach anything meaningful with code exercises in two hours is challenging. I have provided exercises and example code that I think will make this possible. The code is available on GitHub, so you can play with it for yourself: https://github.com/weltraumpirat/repository_workshop.git Of course, this is nowhere near real-life. Please do not take it as a template to design your DDD application by. It is just one possible implementation, and in many aspects incomplete and/or imperfect. Of course, I am not a Java expert. In fact, I haven’t coded anything serious in Java in years. I chose Java, because it has some characteristics that illustrate the effect of repositories. You can help me improve by sending pull requests! Of course, I am very opinionated, anyway. Sorry not sorry. The pictures in this slide deck were created with the help of MidJourney and Photoshop AI. Similarities to real people and/or artwork are purely coincidental.
- 3. Once upon a time,…
- 4. Your company, ChopShop Inc., has recently seen a fast expansion in business, and the demand for new features is ever increasing. The CTO has noticed a sharp increase in delivery times, and as a team, you are quick to assert that the code has become unmaintainable in its current form: It is entangled and messy, business logic is distributed across many modules, it takes hours to fi nd bugs, and fi xes in one place often break things somewhere else. The solution is clear: Microservices.
- 5. You know that microservices are hard to get right, and you want to take no chances. You decide to introduce Domain Driven Design, successfully run an EventStorming, identifying bounded contexts and aggregates, and start separating code into proper modules.
- 6. Exercise #1 You have made progress. But inside of each module, there’s still quite a mess. Rest controllers are huge, containing both domain logic and database queries via JPA. Someone on the team makes good arguments to continue the refactoring towards Hexagonal Architecture. What are some concrete actions you should take? Examine the ShoppingCartController class and discuss options with your teammates.
- 7. Hint #1 The code has full test coverage, it looks better than most code bases, and it looks like we already have repositories… Why do we still need to refactor? Try to imagine a codebase like this, but at scale - hundreds, thousands of classes like this. What could be problematic about the current solution?
- 8. Hint #2 Hexagonal Architecture requires a clear separation of the domain logic from the REST API, the database, third party frameworks, and all other technical details. That means, other parts can depend on the core, but never vice versa. What are possible adapters that you could build? How can you make sure dependencies always point inward, not outward?
- 9. Exercise #2 Your team has been quick to isolate the RestController logic from the domain core, and decide to refactor to CQRS. Now it’s time to introduce a “proper” DDD Repository. What are the necessary steps for the refactoring? Examine the use cases (Commands and Queries) and their implementations, then identify steps to take with your teammates.
- 10. The Repository Pattern in DDD A repository is essentially an interface that hides the details of data access from the domain core. Different storage mechanisms can be attached by creating individual implementations, e.g. for fi le-based storage or per database engine. The interface itself is part of the domain core, the implementation belongs to its environment. Domain objects can pass to the repository and back into the core. They map to serializable data objects. But careful: Business methods must never be invoked outside of the domain core! There are two kinds of repositories: Collection- and Persistence-oriented.
- 11. Collection-Oriented Repositories Collection-oriented repositories act like a collection: They have add(), remove(), addAll() and removeAll(), as well as fi nder methods that allow to search by attribute values. Since a collection does not explicitly notice changes on its member objects, all changes have to be recorded and explicitly “ fl ushed” to the database.
- 12. Persistence-Oriented Repositories Persistence-oriented repositories are save()-based. They make changes more explicit by requiring an extra method call: Any change to a member object is persisted instantaneously by calling save() on the repository. Changes that are not explicitly persisted will be lost. The rule of thumb is: Go with collection-oriented, unless it creates dif fi culties in your context.
- 13. Hint #1 Repositories should map to domain objects, not data transfer objects or database tables. What is the difference? Be mindful of aggregate boundaries.
- 14. Hint #2 Your teammates are worried about data integrity. Where should you place transaction logic?
- 15. Exercise #3 The team has successfully implemented aggregates and a collection- based repository. However, your tests are still very slow - they have to initialize the full Spring context to run, resulting in hours of waiting every week. As a result, more and more colleagues skip tests entirely, resulting in more bugs and rework, which not only led to a number of embarrassing incidents, but also further slows down the delivery. How could those tests be improved? Examine the test code, as well as the newly introduced repository logic, then discuss and implement measures with your teammates.
- 16. Hint #1 All the business logic is now cleanly separated from technical details. It should be testable without external dependencies. Using polymorphism, what could be a quick way to fully isolate the core?
- 17. Hint #2 Dependency injection is just a fancy way of passing constructor parameters. You can eliminate all the expensive setup by making good use of those.
- 18. Exercise #4 You’ve deployed your new microservices on Kubernetes. One month later, your boss calls: The AWS bill is staggering! She urges you to get those spendings down ASAP! Your team investigates, and after looking at some CloudWatch logs, you realize the usage patterns of your app are spiky, high traf fi c times appear random, and there is a lot of idle time - the system should not be running 24/7! You decide to ditch the containers and go full serverless, con fi dent that your system is modular, and should be easy to split up. Discuss the necessary steps. What about your current solution could be problematic?
- 19. Hint #1 Serverless apps are best mapped to individual use cases.
- 20. Hint #2 The collection based repository keeps a lot of in-memory state. This is not helpful and may result in longer runtimes, higher memory consumption, and potential race conditions. What could you do to fi x it?
- 21. Let’s stay in touch! https://mastodon.social/@weltraumpirat https://linkedin.com/in/w3ltraumpirat https://twitter.com/w3ltraumpirat