[SUMMARY] Software Craft - Chapter 11: Architecture

Introduction

In this chapter the authors gave us tips and tricks regarding architecture.

Don't Nest Objects

You often need to interact with other objects. For example when working on a Contract you might often access the related Client.

Nesting object is when you access the Client of a Contract this way:

contract.client.getName()        

However, to reduce coupling and performance issue down the line; it's better to fetch the client:

Orm.getClient(contract.clientId).getName()        

Hexagonal Architecture

The main objective of Hexagonal Architecture is to decouple your business application core logic from external dependency.

It relies on:

• Ports - An abstraction of the external dependency your application logic will rely on.
• Adapters - A concrete implementation of the external dependency.

The main advantages of this kind of architecture are:

• Testable - You can easily test your application by switching adapters and using a test double.
• Future proof - If you want to use a new technology, you just have to modify the adapters.

Change Datatypes

Whether it's a database field, a request field or the response of a service you are likely to modify one of those.

1. Add the new column.
2. Alter the code supposed to write in the column.
3. Wait for all clients to stop using the old column.
4. Delete the old column (optional).

Choreography vs Orchestration

• Choreography - Relies on the observer design pattern (notification through an event bus). It's easy to add, replace, delete parts of the process. However, the whole process is harder to understand/verify.
• Orchestration: The process is centralized in the orchestrator. It's easier to audit and allows integrity of the whole process. However, the orchestrator must change whenever the process changes.

Stateless Service

It's better to have a stateless service. It's less prone to error and more testable.

To do this, you can:

• Use a database.
• Use a JWT token.

Idempotent Service

An idempotent service is a service that is immune to duplicate calls.

For example instead of using a "decrement" function that removes one each time, you can directly set the wanted value. This way, if a message is sent twice by mistake, you get the same result.

You can also use a unique consumable token to avoid duplicate treatment.

Conclusion

This list of tools is not exhaustive, but it's a great starting ground. For more info, you can read books like Clean Architecture by Robert C. Martin.

---

Thank you Cyrille Martraire, Arnaud Thiefaine, ??Dorra BARTAGUIZ, Fabien Hiegel and Houssam F. for writing Software Craft and sharing your experiences!

For more information and details, I highly recommend reading Software Craft!

You can find my summaries of previous chapters in previous articles :)

#softwareCraft #softwareCraftsmanship #architecture #softwareengineering #programing #computerscience #coding #developer #technology #softwaredesign