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”
Tag: architecture
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.
Software Architecture vs. Code – by Simon Brown
Simon Brown talks to us about how, now days, we have many diagramming tools and concepts which some of us like to use, and sometimes are even imposed upon the developers by the corporations managers, who actually have no idea of technicalities and the usefulness or not of those diagrams. However, despite the tools and concepts we have, when we create a diagram of the architecture of a software program we are developing, most of the time it ends up not matching the actual code, we can not see the architecture in the code.
Continue reading “Software Architecture vs. Code – by Simon Brown”
@hgraca 