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”
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.
There are 3 patterns to handle data persistence to relational DBs:
- Active Record
- 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
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”
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.