The original idea was fairly simple.
As software engineers, we spend a lot of time thinking about business logic. We think about the domain model and how to operate on it, the workflows, and the data. These things are obviously important, but a service is more than its business logic.
The things around that logic matter too. How the code is structured. Where responsibilities live. How components communicate. How we expose functionality through APIs. How we deal with failures. How we observe what the system is doing. What we test, and how.
These decisions can have a significant impact on how easy a service is to understand, maintain and change. Because while almost everything about a system will eventually change, the need to deal with that change won't.
The Videos
The first part of my presentation starts by exploring what a service actually is.
The word is used for lots of different things in software engineering. Sometimes it means a class containing some business logic. Sometimes it means a web application. Sometimes it means a microservice. These aren't necessarily the same thing.
I start with the fundamentals before getting into the more interesting architectural decisions. From there, I talk about service boundaries, business capabilities, monoliths and microservices, and the trade-offs involved in choosing between them.
I also cover scaling, observability and APIs, before getting into some of the principles I think are important when designing services. There are plenty of opinions in this part of the talk. Some of them are deliberately stronger than others.
This is where I get into RESTful interfaces, asynchronous communication, security, authentication and some of the ways services interact with each other.
I don't think every architectural decision has one universally correct answer. Context matters. The business matters. The team matters.
But there are some principles I think are worth holding onto.
One of the things I wanted to emphasise throughout the presentation is that good architecture isn't about creating the most sophisticated system possible.
In fact, I think that's often the opposite of what we're trying to achieve.
We're trying to create boundaries that allow things to change independently.
We're trying to keep components cohesive and loosely coupled.
We're trying to make the system understandable to the people who have to work on it six months, two years, or ten years from now.
That doesn't mean we should design everything for a hypothetical future. I've seen plenty of systems where engineers have spent time solving problems they don't actually have.
It means we should make deliberate decisions about where we put our boundaries and understand the consequences when we cross them.
Stand the Test of Time
The title of the talk came from something I've been building towards throughout my career. Software doesn't need to be perfect. It does need to survive change.
The technology will change. The business will change. The people working on the system will change. The scale will change. Requirements will change. Things we thought were temporary will turn out to be permanent, and things we thought were permanent will disappear.
Good software design doesn't prevent that change. It makes the change easier to deal with. That's really what Beyond the Code is about. Not a particular architecture. Not a particular technology. Not a checklist of things every service must have.
It's about the decisions we make around the code that determine how well that code will cope with everything that comes after it.
If you've watched either part, I'd be interested to hear what you think. I'm particularly interested in where you agree, where you disagree, and which of these principles you've found useful in your own systems.
Comments
Post a Comment