So if we decide to think about Bounded Context as a module we can quickly notice that through his definitions it is fully in line with SRP. A situation where a Bounded Context represents concepts that are not related is impossible and may indicate big problems in your modeling of domain. It should be strongly focused around one particular part of the domain, so it has a particular group of stakeholders responsible for its development from the business perspective - its only one actor. In my opinion, the whole DDD is strongly related to the SRP, intentionally or not, and almost all the previously mentioned building blocks are in line with.įor example - Bounded Context. It contains lots of building blocks from high-level concepts like Bounded Contexts to more low-level things like Entities or Value Classes. Single Responsibility Principle And Domain-Driven Designĭomain-Driven Design is all about understanding real-life domains and then expressing them in software we develop. Additionally, in this particular example, our class design has to be flexible enough not to require changes after database schema update.Īfter this, hopefully clear explanation of the SRP in class level context, we will move to describe what we can notice in relation between the SRP and DDD. So, oversimplifying, we can perform a variety of operations as long as they touch only one part of our domain.įor example, in the case of transfers, it should be responsible for incoming transfers only, not outgoing, incoming, and international transfers together. Unfortunately, there is a catch in all of this: it can work this way as long as all of these operations are strongly built around a single business feature. The most important thing is that, in theory, the class can do more than one thing - for example, perform database operations alongside some business logic. Martin’s understanding and mark a single class (to be exact a single public class I assumed that we have one such class in single. When Class Is In Line With Single Responsibility Principle We will start by describing when a singular class is in line with the SRP. Maybe we even see a new meaning in some parts of our application. Such perspective change can be a great deal and help us see our system in totality different ways. It also aims to switch our focus to thinking about why a particular piece of code is doing something rather than actually thinking only about what a piece of code needs to do. As you can see both definitions are quite different from the most common explanation of the Single Responsibility Principle but, in fact, that makes its touch even more visible in some places.Īdditionally, SRP stated that way is more related to the business responsibility of the module rather than exact code inside the module. The term module was originally defined as a single source file while the actor was defined as a person or group of people interested in a particular change. In one of his later books, the author refined it to: “A module should be responsible to one, and only one, actor”. Martin and originally said: “A class should have only one reason to change”. It is the most common explanation of this rule but unfortunately, it is not 100 % in line with what its author wrote. Probably most of you connect the SRP explanation with a statement - class should only do one thing. I will also add some unfunny memes in the meantext. Then I will present all places where the SRP’s touch is particularly visible. I will start by bringing up some basics about what the SRP is - just for everyone to be on the same page. Its touch can be seen on almost all levels of our systems: from single class to whole application (no matter the size and architecture used) design. Today, my dear readers, we will talk about the Single Responsibility Principle, or SRP, which is, in my opinion, the single most important rule in the whole software world.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |