Tidying is term coined by Kent Beck to describe a refactoring approach that aims to demonstrate some simple, fairly black and white scenarios in which code can be meaningfully improved line-by-line.
On service classes
Literal shower thought: don’t create classes like BookingService, do create classes like CreateBookingService. It’s the difference between having a class that is just vaguely about a thing, a booking, and thus becomes a magnet for ANYTHING loosely related to bookings, and instead having a class that is about one thing, creating a booking.
I have tried previously tried to articulate my view on services as “they should be for orchestrating processes”, and this is exactly that, but a lot more focused. A single service is singly responsible for orchestrating one process. It becomes the source of truth for execution of that process. It also now makes more sense to have a service class at all, rather than just doing the thing in a controller directly. In the webinars I linked above the speaker at one point mentions not wanting to do things in a controller and at the time I thought “well why not?”. I still don’t think there’s anything inherently wrong with doing something directly in a controller as long as the rest of the DDD implementation is sound. However there is also likely to be value in being able to test a “process” without needing to concern ourselves with controller concerns.
In DDD I believe these types of services are the “application services”, the services that describe the businesses processes. In clean architecture I thing they are called “use cases”.
What’s cool about this approach is that the tests of the application service can stub out the persistence layer (because it’s behind a repository) and just validate that the process behaves as expected, given a functional persistence layer. Not every single test needs to touch a real database. This gives us the ability to fabricate data in whatever shape we want to easily create test scenarios.
^^ this right here is why repository pattern and the other decoupling is so helpful. Not only can you test the core of your application, you can test all the processes in a way that doesn’t have to care about presentation or persistence concerns.
Principle of least surprise is at play here too. A system built with DDD and clean/hexagonal architecture is going to be much more predictable to navigate. Consider a key process in the domain of the system I am working in. Can I easy identify where that flow happens in the code?
See Also
Related Notes
- Good Software Practices - Broader engineering principles
- System Design - Architecture and design patterns
- Testing - Testing and quality assurance
Reading List
- A Philosophy of Software Design - Design principles from John Ousterhout
- Working Effectively with Legacy Code - Refactoring and improving existing code
- Head First Design Patterns - Classic design patterns
- The Clean Architecture - Architectural boundaries and dependencies
Back to
- Notes - All engineering notes