Contains exercises and hints, as well as a link to the source code examples.

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