segunda-feira, 14 de setembro de 2015
New systems usually have the need to communicate with legacy to dispose of some feature. The new system's model probably is different from the legacy model, considering that legacy model is usually weak. This discrepancy results in compatibility problems when integrating these two systems. Two systems with a well designed model wouldn't have this problem.
When this communication is required, the new model can be badly affected/influenced, because probably there will be a difficulty communicating both systems due to incompatibilities, for example, different data structures, protocols, and even pieces of the model. This can result in the distortion of the new model because of the need of the link between the new generation and the legacy.
One solution for this problem is a layer between both systems doing this adaptation, exposing the feature required through interfaces abstracting details of the implementation. This is the Anti Corruption Layer, a layer that makes this adaptation and the "dirty work", building a layer responsible for doing this translation. It's usually done through services exposing interfaces well defined with the required features.
One way for building the Anti Corruption Layer is by mixing the patterns Facade and Adapter, that are also mentioned on the book Domain Driven Design.
The facade is an alternative that simplify the access to a sub system. It exposes the features hiding implementation details, leaving for the consumer just the work of referencing the interface representing the feature. The adapter is like a wrapper that allows two incompatible functionalities to work together. It does the job of adapting the feature, creating a compatible interface between both implementations. These patterns will can be better explained with examples in a future post.
The image below shows two systems and the Anti Corruption Layer between them using these two patterns to hide the implementation details and to do the adaptability between them.
The Anti Corruption Layer's main goal is to link two bounded contexts/sub systems, and preserve the new model by not polluting it with possible problems when integrating with other sub systems.
It's always good to emphasize the importance of creating tests when doing this kind of integration, the tests will assert that the implementation is doing what is expected, avoiding surprises ahead.
domingo, 9 de agosto de 2015
First of all, let's install RabbitMQ. In my case, I use Ubuntu 15.04, here are the steps for installing RabbitMQ:
- sudo apt-get install rabbitmq-server
On python side, I've used a lib called Pika. I've made the installation using pip, here is the command:
- pip install pika
The codeThe example shown below is divided into three parts: sender, receiver and main program exploring the basic features in a simple and clear code.
Concluding, the intent of this post was to show a way of working with messaging and python. This example was simple, but it's a good start point for who wants to play with messaging and python. Particularly I love python programming, it was a nice experience and I pretend to evolve more this example, showing advanced features and more fun things.
You can check the code on my github: https://github.com/marcelocure/sandbox/tree/master/python/python_messaging
domingo, 5 de julho de 2015
Continuing our line about clean code, let's talk about Single Responsibility Principle, the first of the five SOLID principles.
The Single Responsibility Principle tells us the class must have one responsibility and one reason to change. Again, here's another citation from Robert Martin:
"A class should have one, and only one, reason to change"Each class must have one responsibility, and it means that this class should do one thing, this way, having one reason to change. Let's analyze the class below and identify the responsabilities it has:
Clearly this class is doing more than one thing. The first one is to make the authentication, the second one is to create the session. In this case, with two responsibilities, this class becomes more complex, hard to test, highly coupled and hard to maintain, probably resulting in bugs.
Let's say the system needs a maintenance on the creation of the session, the details about how to create the session is not related to authentication, the developer must read the class name and understand what it should do exactly, in this case, authenticate a user. If I had the task to make this maintenance, I would find for a class called SessionManager or something like this to make the required changes.
The code below is how I imagine it should be:
Some of the goods of this principle:
- Code more readable and clean;
- Code more testable;
- Less mocks on the tests;
- Less complexibility;
- Easy to maintain.
Classes should do one thing, it will make everyone happier, who writes the class, who creates tests and who makes some maintenance on it. Having one responsability on the class, it will avoid many problems and make the project cleaner and easier to maintain.
sexta-feira, 26 de junho de 2015
When we talk about clean code, the first thing that comes to my mind is to give the intent of the code we're writing. When we write some piece of code we want to make it clean, it also means we want to clarify the intent of that unit. Choosing good names for classes, methods, attributes, etc is one way to achieve this. Here is a citation from Robert Martin on Clean Code book:
"Choosing good names takes time but saves more than it takes."
It seems to be something very basic, but many times we're writing code, thinking the names we're giving the Classes/Methods/Attributes are clear enough, and actually it's not that clear. At that moment it seemed that name was the best, the clearer, but if you read that piece of code two or three hours later, you'll probably notice that the name you choose was not transmitting your intent, or at least you will find a better name.
Where there is a comment near a method name for example, It means the author could not reveal the intent of that method. Meaningful names dispense comments.
A classic example is the variables named "a", "b", "c", etc. Here is an example of a method for calculating taxes over a banking transfer:
Once someone who's gonna consume this method looks at its signature, this doubt will appear. What the hell is "a"? What about "b"? Here the developer could have chosen better names for the parameters and even for the method name. Let's express the method intent with well written names:
Now looking at the method signature, it's way clearer. Now the consumer will understand the intent of the method and the meaning of the attributes.
Still there are a lot of other techniques to write clean code and avoid other programmers's suicide when trying to understand what's been written and how to use it.