Learning Test-Driven Development

Chapter 11. Banking on Redesign

On the whole it’s worth evolving your design as your needs grow…¹

Martin Fowler, Patterns of Enterprise Application Architecture (Addison-Wesley, 2002)

We introduced the Portfolio entity back in Chapter 3. It represents a key concept from our domain, so we’re justified in giving it some responsibility. Now, our Portfolio does too much work and it shows. Its primary job is to be a repository of Money entities. However, it has taken on the added responsibility of converting between currencies. To do this, it has to hold on to an exchange rate table and the logic to do the conversion. This doesn’t look like the responsibility of a Portfolio. Monetary conversion has as much business being in a portfolio as peanut butter has being on top of a pizza.

Our software program has grown along with our needs. It is worth improving our design and looking for a better abstraction than the shoved-in way conversion between currencies is currently implemented.

A principle of domain-driven design (DDD) is continuous learning. When we learn something new about our domain, we let our design reflect our acquired knowledge. The resulting design and software should reflect our improved understanding of our domain.

Tip

Domain-driven design is a discipline that’s ably supported by TDD. Eric Evans’ book of the same title is the seminal work on the subject.

By implementing currency conversion over the last few chapters, we have gained fresh insight into our program. It’s ...