This is a very interesting, short and pragmatic talk, by Nicole Forsgren, where she talks about the DevOps role in an IT company.
Continue reading “The Dev0ps role and the company culture – by Nicole Forsgren”
Category: Development
All development
DDD.6 – The lifecycle of a domain object
There are three main objects that can control the life-cycle of a domain object:
- Aggregates: Hold several objects in a root object and can control their creation, manipulation, query and deletion;
- Factories: Create new objects with a set of data;
- Repositories: Recreate persisted objects from queried data, possibly delegating the reconstruction of the actual object instance to a factory.
DDD.5 – A model expressed in software
A model is expressed in code by several patterns of model elements:
- Value objects
- Entities
- Associations
- Services
- Packages
- Modules
“Expecting professionalism” by Robert C. Martin
“The reasonable expectations of your new CEO”
There is software everywhere! And it must be work! It must not fail! People depend on it!
Continue reading ““Expecting professionalism” by Robert C. Martin”
“The responsibility of knowing” by Robert C. Martin
This post is my personal notes of the talk “The responsibility of knowing” by Robert C. Martin.
The responsibility of knowing
Engineers are creators, inventors, they know how to build things, how things work, what can fail, what will fail, when it will fail. Engineers have the knowledge, and that means they have great power, and “with great power comes great responsibility”.
Continue reading ““The responsibility of knowing” by Robert C. Martin”
Clean Code I: Arguments by Robert C. Martin (Uncle Bob)
This post is my personal notes of the talk “Clean Code I: Arguments” by Robert C. Martin.
Clean Code 1: Arguments
Bad code slows you down. You write it under business pressure, because there is no time, the client needs the feature yesterday, the feature was sold before it was build, maybe even before it was ever thought of by the team, or any other reason. But the real truth is:
There is not excuse to write bad code!
Continue reading “Clean Code I: Arguments by Robert C. Martin (Uncle Bob)”
DDD.4 – Isolating the domain
In order to easily identify, understand and manipulate the code that reflects the domain, we need to isolate it from all the support code, the code that allows for user interaction (views, controllers) and the code that allows for data persistence and retrieval.
The most widely used and easy to understand approach is to isolate the code into layers:
- User interface: Views to interact with the user;
- Application: Controllers to specify use cases;
- Domain: Business rules that reflect the model;
- Infrastructure: Persistence, queues, … ;
DDD.3 – Binding model and implementation
The implementation design must be easily and accurately mapped to the model, otherwise the model is of little use. Easier said than done though.
Anyway, the process should start by creating a simple but very accurate design of a small part of the domain. This inicial design should then be revisited, improved, incremented and re-factored in order to reflect a bigger set of the domain, in a way more suited to the actual implementation.
When to use events
Typically, in a layered architecture, the top layers are aware of the lower layers and start logic in the lower layers. But, the lower layers are not aware of the layers above and can not start logic in the layers above. However, in highly complex situations, the lower layers might need to fire logic in the top layers.
DDD.2 – Communication and the use of language
As in any activity, fast, easy and clear communication is essential for a good performance.
In a software development project, both domain experts and developers have their own language, with its own jargon and specificities. Both team member types are usually unaware of the others language, so it must be created a common language that everyone can understand without any ambiguity.
Continue reading “DDD.2 – Communication and the use of language”
@hgraca 