What do we talk about when we talk about software architecture? Truth is there is no fixed definition but a wide range of debates and opinions about it. Each and every one of them objetable and discussable.
Architecture can be considered to be the fundamental organization of a system, meaning the most important aspects of a software system’s internal design or how the higher level components are connected. But how or who defines what is fundamental or high level? Tricky, huh?
We could also think that the architecture is the decisions that must be made at the beginning of a project, although to be honest, it’s mostly about the decisions one wishes to have made correctly at the beginning of a project.
Tell dont ask is a principle of object-oriented programming that helps us remember that this paradigm is about creating objects with logic that operate on their data. To clarify, instead of asking an object for data and acting on that data, we should tell the object what to do because it knows its data.
Test Driven Development is a software design technique that suggests we start our code with a test and build the design from it. Some of it’s main promoters are Kent Beck, Robert Martin, Sandro Mancuso, etc. Despite the subtle differences between them, they all agree on the same guidelines. Some of it’s advantages are a better coverage of automated tests, a better software design and fewer bugs, among others. Next, some characteristics of the classical idea by way of introduction will be detailed.
Domain events are one of the tactical design patterns of Domain Driven Design (DDD).
They appeared after the blue book where Eric Evans introduces the core concepts of DDD. They had a great impact on the community because of the possibilities they provide.
On the strategic side of DDD, the community discovered that focusing on the main events that occurs on the business leads to a better understanding of the problem domain (for example that a customer made a purchase or that a product is ready to be shipped).
Events are a great tool that allows discovering and understanding complex business flows involving different actors.
This principle states that an entity (class, module, function, etc) must be open for extension but closed for modification. We must be able to extend the behavior of our entities, without the need to modify its code.