You may be wondering who we are and why we wrote this book.
And then he was lucky enough to run into Bob, who has the answers to all thesequestions.
Bob ended up a software architect because nobody else on his team wasdoing it. He turned out to be pretty bad at it, but he was lucky enough to runinto Ian Cooper, who taught him new ways of writing and thinking about code.
Managing Complexity, Solving Business Problems
We both work for MADE.com, a European ecommerce company that sells furnitureonline; there, we apply the techniques in this book to build distributed systemsthat model real-world business problems. Our example domain is the first systemBob built for MADE, and this book is an attempt to write down all the stuff wehave to teach new programmers when they join one of our teams.
MADE.com operates a global supply chain of freight partners and manufacturers.To keep costs low, we try to optimize the delivery of stock to ourwarehouses so that we dont have unsold goods lying around the place.
Ideally, the sofa that you want to buy will arrive in port on the very daythat you decide to buy it, and well ship it straight to your house withoutever storing it. Getting the timing right is a tricky balancing act when goods takethree months to arrive by container ship. Along the way, things get broken or waterdamaged, storms cause unexpected delays, logistics partners mishandle goods,paperwork goes missing, customers change their minds and amend their orders,and so on.
We solve those problems by building intelligent software representing thekinds of operations taking place in the real world so that we can automate asmuch of the business as possible.
Why Python?
If youre reading this book, we probably dont need to convince you that Pythonis great, so the real question is Why does the Python community need a booklike this? The answer is about Pythons popularity and maturity: although Python isprobably the worlds fastest-growing programming language and is nearing the topof the absolute popularity tables, its only just starting to take on the kindsof problems that the C# and Java world has been working on for years.Startups become real businesses; web apps and scripted automations are becoming(whisper it) enterprisesoftware .
In the Python world, we often quote the Zen of Python:There should be oneand preferably only oneobvious way to do it.Unfortunately, as project size grows, the most obvious way of doing thingsisnt always the way that helps you manage complexity and evolvingrequirements.
None of the techniques and patterns we discuss in this book arenew, but they are mostly new to the Python world. And this book isnta replacement for the classics in the field such as Eric EvanssDomain-Driven Designor Martin Fowlers Patterns ofEnterprise Application Architecture (both published by Addison-Wesley Professional )which we often refer to andencourage you to go and read.
But all the classic code examples in the literature do tend to be written inJava or C++/# , and if youre a Python person and havent used either ofthose languages in a long time (or indeed ever), those code listings can bequitetrying. Theres a reason the latest edition of that other classic text, FowlersRefactoring (Addison-Wesley Professional), is in JavaScript.
TDD, DDD, and Event-Driven Architecture
In order of notoriety, we know of three tools for managing complexity:
Test-driven development (TDD) helps us to build code that is correctand enables us to refactor or add new features, without fear of regression.But it can be hard to get the best out of our tests: How do we make surethat they run as fast as possible? That we get as much coverage and feedbackfrom fast, dependency-free unit tests and have the minimum number of slower,flaky end-to-end tests?
Domain-driven design (DDD) asks us to focus our efforts on building a goodmodel of the business domain, but how do we make sure that our models arentencumbered with infrastructure concerns and dont become hard to change?
Loosely coupled (micro)services integrated via messages (sometimes calledreactive microservices) are a well-established answer to managing complexityacross multiple applications or business domains. But its not alwaysobvious how to make them fit with the established tools ofthe Python worldFlask, Django, Celery, and so on.
Note
Dont be put off if youre not working with (or interested in) microservices. The vast majority of the patterns we discuss, including much of the event-driven architecture material, is absolutely applicable in a monolithic architecture.
Our aim with this book is to introduce several classic architectural patternsand show how they support TDD, DDD, and event-driven services. We hopeit will serve as a reference for implementing them in a Pythonic way, and thatpeople can use it as a first step toward further research in this field.