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”
Category: Patterns of Enterprise Application Architecture by Martin Fowler
PEAA.8 – Putting it all together
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”
PEAA.7 – Distribution strategies
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:
- REST
- Microservices
- Cheat Sheets
- Micro-Services – Martin Fowler
- ArrrrCamp 2015 – Stop Building Services, Episode 1: The Phantom Menace by Rachel Myers
- Principles Of Microservices by Sam Newman
- and many more videos in Youtube and articles throughout the web.
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.
PEAA.6 – Session state
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”
PEAA.5 – Concurrency
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”
PEAA.4 – Web Presentation
Back when this book was written, using the web for building enterprise applications was a new practise.
Although, in the beginning, it was a common practise to mix presentation logic with business logic and even persistence logic (think HTML mixed with SQL), it soon became clear that it was very difficult to change the UI if it was not decoupled from all other logic.
The MVC patter, which was around since the late 1970s, came to the resqueue and became the common practise. The most important reason to use MVC is to decouple presentation logic from business logic.
PEAA.3 – Mapping to relational DBs
There are 3 patterns to handle data persistence to relational DBs:
- Active Record
- Gateway
- Data Mapper
Associated to this patterns, we have a few more design patterns to help implement the previous ones:
- Unit of work
- Identity map
- Lazy loading
And we also have 3 patterns to structure the data in the DB:
- Single table inheritance
- Concrete table inheritance
- Class table inheritance
Continue reading “PEAA.3 – Mapping to relational DBs”
PEAA.2 – Organizing Domain Logic
Properly organizing the code and specially the domain logic is crucial for the maintainability of a project.
Personally, it reminds me of a book store or library: If we put a book in the wrong shelve, the people looking for the book will not find it, it will be lost, another copy of the book will be ordered, catalogued and stored in some other place, hopefully in the correct place where people will find it and therefore use it.
It happens the same with our code, if we don’t have a clear place to put a specific code unit, the developers (our colleagues or even one self) will not know of its existence, they will think it does not exist, they will create it again (wasting time, wasting resources, duplicating code, …), they will create it slightly differently, introducing inconsistency throughout the code base.
The folders we use in the project structure should correspond to bounded contexts, which correspond to business concepts, and in them there should be a clear functional separation, a separation per code unit role. Continue reading “PEAA.2 – Organizing Domain Logic”
PEAA.1 – Layering
Layering is a common practice to separate and organise code units by their role/responsibilities in the system.
In a layered system, each layer:
- Depends on the layers beneath it;
- Is independent of the layers on top of it, having no knowledge of the layers using it.
@hgraca 