Presenter: Matteo Vaccari
Objective(s) of the session:
Learn how to organize code so that the domain model is clearly separated from the technical infrastructure and external APIs. Learn how to refactor towards such an architecture. Improve refactoring skills.
Contents:
This is a little programming kata that gets you to think: how to organize an application so that the domain logic is separated from external libraries and systems? The example reads person records from a file and sends email to selected persons. How do you test this properly? By "properly", I mean that
- the core logic of your application should be tested without need to talk to the filesystem or the mail server.
- you should be able to prove that the system interacts correctly with both the filesystem and the mail server.
How do you separate responsibilities? The "Single Responsibility Principle" says that a class should have a single reason to change. This means that we should have a single place in the code that changes in the event that, say:
- the data comes from a database instead of a file
- instead of sending email, we want to send a FaceBook? message or a text message
- the logic for deciding who gets the messages changes
- the content of the messages changes
In this session you will learn about
- The hexagonal architecture, which is a variant of the common three-layers architecture. The advantage is that it avoids making the domain model dependent on the data-access code.
- The dependency-inversion principle, which says that high-level code should not depend on low-level details, and how to implement it.
- Splitting your code in
- unit tests, which prove that your logic works, and are fast and reliable, and
- integration tests, which prove that you can talk to external systems, but are a bit less fast and a bit less reliable.
This session was prepared within the Orione team, and was presented to the Milano XP User Group.
Format and length: 120 mins coding dojo. Participants should provide their own laptop. I provide the necessary software.
Process and timetable:
- 15 minutes of presentation. I explain the problem, and what we want to achieve
- 10 minutes show the code. We look at the sample code and discuss how it works, and why it needs refactoring.
- 5 minutes pause
- 25 minutes The participants are split in pairs. First session of coding and refactoring.
- 5 minutes pause
- 25 minutes change pairs. more coding.
- 5 minutes pause
- 10 minutes the participants do a perfection game with their pair
- 10 minutes a representative of each pair tells their story to the audience
- 5 final comments and discussion
Intended audience and prerequisites:
This session is for programmers who are beginners to intermediate in TDD and refactoring. Knowledge of Java is preferred. .Net programmers will need to pair with a Java programmer. This is not a session for absolute beginners; I expect the audience to have a basic idea of what TDD and refactoring are and why they're good.
What do the presenters expect to learn from the session?
I expect to sharpen my skill in teaching agile engineering practices in general. I hope to get ideas on how to improve and expand this material.
Materials needed, room layout, limitations...:
We need a projector, and tables for pair programming.
References:
