Category: Development

All development

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.

Continue reading “PEAA.4 – Web Presentation” →

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” →

DDD.16 – Large-scale structure

Segregating the domain into bounded contexts its a good start into maintainability, however if in every bounded context we have a different structure it can and will become cumbersome to understand the current bounded contexts and to further develop new bounded contexts.

For this reason, the team should rely on a simple generic structure to follow in every bounded context. This way, every developer in the team will be familiar with the global structure of every bounded context, making communication and collaboration easier between developers and teams.

Nevertheless, this does not mean the structure must be frozen. It can, and should, evolve as needed. Continue reading “DDD.16 – Large-scale structure” →

DDD.15 – Distillation

Distillation is the process of identifying the domain, decoupling it, isolating it, clarifying it and making it explicit, allowing us to focus on what is more relevant and having it maintainable.

There are a few techniques that can be used to distil a model.

Each of these techniques requires a successively greater commitment, but a knife gets sharper as its blade is ground finer. Successive distillation of a domain model produces an asset that gives the project speed, agility, and precision of execution.

e-book loc. 6509

Going through this distillation process has several benefits:

  • Makes the overall design explicit and known;
  • Distinguishes what is Core Domain from what is Generic Domain, reducing them to manageable sizes;
  • Focus the software evolution (development and refactoring) in what is more relevant at a given moment.

Continue reading “DDD.15 – Distillation” →

DDD.14 – Maintaining model integrity

When working in a large system, with a large model where we have several teams working on it, a section of the model will likely end up being interpreted, and adjusted in code, in different ways by the different teams.

These different interpretations and code adjustments will end up corrupting the model, leading to incoherent code and eventually bugs.

The best way to deal with this issue is to break the large model into smaller independent models. Breaking down a model is done by identifying bounded contexts and using context maps to identify their borders and relationships between them.

Continue reading “DDD.14 – Maintaining model integrity” →