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.
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.
Format and length: 120 mins coding dojo. Participants should provide their own laptop. I provide the necessary software.
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.