Devops for Growth

Rédiger un DAT peut parfois ressortir de l’exploit si celui-ci est mis en application et évolue avec la réalisation de l’application.

Je vous propose de nous reposer sur l’urbanisation des services d’informations. Cela consiste à découper le SI en modules autonomes, de taille de plus en plus petite :

• les zones,
• les quartiers (et les îlots si nécessaire),
• les blocs (blocs fonctionnels)

Ce principe peut être mis en place pour les architectures applicatives.

Remember that such things as web services are also presentations, even though they are used by computer users rather than human users. So don't intermix domain code with the code required to support a web service, or indeed any other external API.

Observer Gotchas

Many interactions in a rich client presentation make use of the Observer pattern. Observer is a useful pattern, but it comes with some important issues that you need to be aware of.

The great strength, and weakness, of observer is that control passes from the subject to the observer implicitly. You can't tell by reading code that an observer is going to fire, the only way you can see what's happening is to use a debugger. As a result of a complex chain of observers can be a nightmare to figure out, change, or debug as actions trigger other actions with little indication why. As a result I strongly recommend that you use observers only in a very simple manner.

• Don't have chains of objects observing other objects, observing other objects. One layer of observer relationships is best (unless you use an Event Aggregator
• Don't have observer relationships between objects in the same layer. Domain objects shouldn't observe other domain objects, presentations should not observer other presentations. Observers are best use across the layer boundary, the classic use is for presnetations to observer the domain.

Another issue for observers lies in memory management. Assume we have some screens observing some domain objects. Once we close a screen we want it to be deleted, but the domain objects actually carry a reference to the screen though the observer relationship. In a memory-managed environment long lived domain objects can hold onto a lot of zombie screens, resulting in a significant memory leak. So it's important for observers to de-register from their subjects when you want them to be deleted.

A similar issue often occurs when you want to delete the domain object. If you rely on breaking all the links between the domain objects this may not be enough since screens may be observing the domain. In practice this turns out be a problem less frequently as the screen departs and the domain objects lifetime are usually controlled through the data source layer. But in general it's worth keeping in mind that observer reltionships often hang around forgotton and a frequent cause of zombies. Using an Event Aggregator will often simplify these relationships - while not a cure it can make life easier.

Tackling complexity in large Software Systems was always a daunting task since the early days of Software development (1960's). Over the years, Software Engineers and Architects made many attempts to tackle the complexities of Software Systems: Modularity and Information Hiding by David Parnas (1972), Separation of Concern by Edsger W. Dijkstra (1974), Service Oriented Architecture (1998).

All of them used the age-old and proven technique to tackle the complexity of a large system: divide and conquer. Since the 2010s, those techniques proved insufficient to tackle the complexities of Web-Scale applications or modern large-scale Enterprise applications. As a result, Architects and Engineers developed a new approach to tackle the complexity of Software Systems in modern times: Microservice Architecture. It also uses the same old “Divide and Conquer” technique, albeit in a novel way.

Software Design Patterns are general, reusable solutions to the commonly occurring problem in Software Design. Design Patterns help us share a common vocabulary and use a battle-tested solution instead of reinventing the wheel. In a previous article: Effective Microservices: 10 Best Practices, I have described a set of best practices to develop Effective Microservices. Here, I will describe a set of Design Patterns to help you implement those best practices. If you are new to Microservice Architecture, then no worries, I will introduce you to Microservice Architecture.

By reading this article, you will learn:

• Microservice Architecture
• Advantages of Microservice Architecture
• Disadvantages of Microservice Architecture
• When to use Microservice Architecture
• The Most important Microservice Architecture Design Patterns, including their advantages, disadvantages, use cases, Context, Tech Stack example, and useful resources.

Please note that most of the Design Patterns of this listing have several contexts and can be used in non-Microservice Architecture.