More on this book
Community
Kindle Notes & Highlights
by
Sam Newman
Read between
December 3 - December 3, 2015
Eric Evans’s book Domain-Driven Design (Addison-Wesley) helped us understand the importance of representing the real world in our code,
Alistair Cockburn’s concept of hexagonal architecture
What Are Microservices? Microservices are small, autonomous services that work together.
Small, and Focused on Doing One Thing Well
Single Responsibility Principle, which states “Gather together those things that change for the same reason, and separate those things that change for different reasons.”
Jon Eaves at RealEstate.com.au in Australia characterizes a microservice as something that could be rewritten in two weeks,
how well the service aligns to team structures. If the codebase is too big to be managed by a small team, looking to break it down is very sensible.
with microservices, we can build systems that handle the total failure of services and degrade functionality accordingly.
smaller teams working on smaller codebases tend to be more productive.
How often have you deleted more than a hundred lines of code in a single day and not worried too much about it?
Service-oriented architecture (SOA)
breaking down a codebase into multiple libraries.
creating code for common tasks that aren’t specific to your business domain that you want to reuse across the organization,
modular decomposition techniques
We aren’t medical doctors or engineers, but nor are we plumbers or electricians. Instead, we fall into some middle ground, which makes it hard for society to understand us, or for us to understand where we fit.
Architects and engineers have a rigor and discipline we could only dream of, and their importance in society is well understood.
in the eyes of the law I am now a qualified architect and I should be held responsible if I get it wrong.”
In the UK, for example, a minimum of seven years study is required
I wouldn’t say that buildings and bridges never fall down, but they fall down much less than the number of times our programs will crash, making comparisons with engineers quite unfair.
Our software isn’t constrained by the same physical rules that real architects or engineers have to deal with, and what we create is designed to flex and adapt and evolve with user requirements.
Our requirements shift more rapidly than they do for people who design and build buildings
The things we create are not fixed points in time. Once launched into production, our software will continue to evolve as the way it is used changes.
we have to accept that once the software gets into the hands of our customers we will...
This highlight has been truncated due to consecutive passage length restrictions.
focus on helping create a framework in which the right systems can emerge, and continue to grow as we learn more.
we should think of our role more as town planners than architects for the built environment.
The city changes over time. It shifts and evolves as its occupants use it in different ways, or as external forces shape it.
our system doesn’t just accommodate users; it also accommodates developers and operations people who also have to work there,
A town planner, just like an architect, also needs to know when his plan isn’t being followed.
As architects, we need to worry much less about what happens inside the zone than what happens between the zones. That means we need to spend time thinking about how our services talk to each other, or ensuring that we can properly monitor the overall health of our system.
“be worried about what happens between the boxes, and be liberal in what happens inside.”
The Coding Architect
I cannot emphasize how important it is for the architect to actually sit with the team! This is significantly more effective than having a call or just looking at her code.
Strategic goals should speak to where your company is going, and how it sees itself as best making its customers happy.
If you’re the person defining the company’s technical vision, this may mean you’ll need to spend more time with the nontechnical parts of your organization (or the business, as they are often called).
Principles are rules you have made in order to align what you are doing to some larger goal,
Heroku’s 12 Factors are a set of design principles structured around the goal of helping you create applications that work well on the Heroku platform.
should be low level enough that any developer can understand them.
Practices could include coding guidelines, the fact that all log data needs to be captured centrally, or that HTTP/REST is the standard integration style.
if you support only CentOS, this will need to be reflected in your practices.
las practicas se tien que ver reflejadas en el trabajo
You might decide to call the use of HTTP/REST a principle rather than a practice, for example. And that would be fine.
Figure 2-1. A real-world example of principles and practices
Ben Christensen from Netflix puts it, when we think about the bigger picture, “it needs to be a cohesive system made of many small parts with autonomous lifecycles but all coming together.”
contratos entre las aplicaciones
Monitoring
Interfaces
Architectural Safety
If your circuit breakers rely on HTTP codes, and one service decides to send back 2XX codes for errors, or confuses 4XX codes with 5XX codes,
What if, out of the box, the developers had most of the code in place to implement the core attributes that each service needs?
Governance and Leading from the Center
Normally, governance is a group activity. It could be an informal chat with a small enough team, or a more structured regular meeting with formal group membership for a larger scope.
