This chapter of the book talks about the people involved in the system development and the processes that guide their work:
- The value stream
- The key stakeholders
- The process of stakeholders engagement
- The network of stakeholders
As there is a lot to cover in this chapter, I will make several posts to cover it in small batches.
In this post, I will write about the value stream.
Continue reading “Stakeholder engagement: The value stream”
Chapter two of the book is a small preview of the whole book, where the authors talk a bit about:
- engaging the stakeholders
- defining the problem
- what the system is
- what the system does
- the code
Continue reading “Agile Production in a Nutshell”
Lean, agile, architecture… This book’s intention is to teach us about lean architecture for agile software development, how we can use the planning values of lean to drive the inspect-and-adapt (short feedback loop) principles of agile.
This first chapter clarifies the concepts of Architecture, Lean and Agile and why we need Lean Architecture.
In today’s fast-paced world, change is the most stable constant.
In order to thrive, a product must swiftly adapt to changes. For this reason, we need Agile methodologies, to have a project (and the team developing it) embrace change and react to it fast to give the product a competitive advantage and keep it in the game.
However, it is difficult to reshape a system if it is cramped with clutter, if to change part of it, we need to change other unrelated parts who might not even be in use. And here enters Lean.
Lean practices help us get rid of the clutter so we can use agile practices to focus on quickly delivering value to the end-user, by delivering basic functionality and iterating on it to deliver better quality. Continue reading “Lean Architecture”
An application is made of several components and sub-components, all of which are essential to the functioning of the application. However, there are components more important than others. Continue reading “PPPDDD.3 – Focusing on the Core Domain”
Building software that works is not difficult.
What is indeed difficult is to build software that lasts for many years, that keeps working despite the changes needed by the business, needed by the users, needed by new technologies. Building software that is permanently ready for change, and permanently and accurately reflects the business… thats the tricky part. Continue reading “PPPDDD.1 – What is Domain Driven Design?”
I find the reading of pattern description to be tedious, and the whole part 2 of the book, from chapter 9 to 18, is a listing of design patterns. Therefore I will simply list them with their one sentence description. Continue reading “PEAA – Part 2 – The patterns”
This chapter is a bit more than a revision to the previous chapters. Much of what Fowler states, is outdated. Many of the questions he had at the time are not questions any more, they are certainties, some were even trendy and are currently outdated.
In any case, mixing his view at the time with my understanding of what is common practice now days, this is what I take out of this chapter. Continue reading “PEAA.8 – Putting it all together”
This chapter talks about options to build a distributed system. However it is extremely outdated, as an example I quote ” SOAP is probably going to be the most common form…”. It turns out that the SOAP golden days were not there yet and currently have already passed. Now days most distributed systems are doing Microservices through RESTfull interfaces.
If we want to dive into this subject there are plenty of resources out there:
This post is part of a set of posts with my personal notes about all the chapters in the book “Patterns of Enterprise Application Architecture” by Martin Fowler. I will do this as I read through the book, and take notes on the concepts I personally find more relevant.
Stateless objects are objects with no properties. However when we talk about a stateless server, we are talking about an architecture where the objects do not retain state between requests. This does not mean that the data is lost between requests, it merely means that the data is somehow temporarily persisted during the business transaction, the process handling the request is terminated and the server resources are freed. A new request can, then, resurrect the temporarily persisted data and continue the business transaction.
HTTP servers are stateless, as is the HTTP protocol. Despite this, when we look at a shopping cart in a web shop, we have a session and the items in the cart are preserved between requests without the business transaction been finished and its data being permanently persisted. This makes it in fact a stateful session. Continue reading “PEAA.6 – Session state”
Concurrency occurs when different processes or applications need the same resource to continue to work. To understand when this happens and how to deal with these issues, we need to talk about execution contexts, racing conditions, inconsistent reads, deadlocks and transactions. Continue reading “PEAA.5 – Concurrency”