small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

In the previous article, we encouraged making certain architectural decisions that can influence the final shape of application architecture. In this article, we will look at popular application architectures and how to create your own solution based on them. We will also identify the GRASP responsibilities presented in the first article within the layers of well-known application architectures.

#### Multilayer Architecture

The most popular multilayer architecture is the three-layer architecture, and its most notable representative is the MVC architecture or Model-View-Controller. MVC divides our application into three layers according to three responsibilities. Let's map them to responsibilities according to GRASP.
![blog-grafika 2.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_2_ead357b314.jpg)

- **Controller**: Responsible for coordinating workflow, serving as the Controller in GRASP. It may also be responsible for creating instances of Model objects, thus fulfilling the Creator function, and communicating with the database, which will be realized as Pure Fabrication. In MVC, the Controller is the entry point to the application.
- **Model**: This layer contains data and behaviors that can represent business logic, making it an Information Expert equivalent. The Model can be either a rich or anemic entity. Often, database communication is handled within this layer (instead of at the Controller level). However, it may be a good idea to separate persistence from logic, even if our Model also serves as a database model.
- **View**: Maps data from the model to views returned to the user, performed by Pure Fabrication services. Such a view can be a simple JSON object or a rich HTML view.

A simple multilayer architecture is beneficial in simple APIs where the backend application primarily serves to store and read data. In most cases, we will deal with such applications in simple API implementations within frontend frameworks.

Within the multilayer architecture, we have the flexibility to choose layers. We can often limit ourselves to just two layers, for example, a coordination layer and a business logic layer, where the view is part of the Controller's response. This especially makes sense if we use the previously mentioned CQRS or CQS. The Controller calls operations on the model, which returns nothing, and then queries the repository responsible solely for reading in the View layer.


#### Clean Architecture

Clean architecture is much more complex than multilayer architecture. It also has layers, although they are directed inward, unlike the layers in MVC. The workflow is from the outer layer to the inner and then from the inside out. At the same time, the direction of dependencies remains unidirectional inward through the proper use of programming interfaces (those interested should read about the "dependency inversion principle").

![blog-grafika 1.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_1_350cca9c14.jpg)

Clean architecture has three layers:
- **Infrastructure Layer**: Often divided into two layers - ports and adapters, where ports are objects allowing entry into the application (e.g., HTTP controller), and adapters are entries to other devices (e.g., databases or other external services). The infrastructure layer is the outer layer, the only one interacting with the outside world, including dependent libraries or frameworks. This layer handles data reading (Query from CQS/CQRS) and writing. Objects in this layer fulfill Pure Fabrication and Creator responsibilities from GRASP.
- **Application Layer**: A higher layer independent of the infrastructure layer. Its task is to coordinate specific use cases. It is independent of the framework and external libraries. Use cases (represented as services performing one specific task) fulfil the Controller's responsibility from GRASP. Typically, their role is to delegate tasks, fetch and save data to the lower layer and execute business logic code to the higher layer.
- **Domain Layer**: This layer contains domain services and entities (usually rich) that perform operations on data and change the application's state. This layer is independent of persistence, which is delegated by the application layer to the infrastructure. Domain layer objects fulfil the Information Expert role from GRASP.

Clean architecture can effectively separate client business-related aspects from technical details. However, it is quite complex, making it worth using for more complex systems where we will benefit from it.

As can be seen, this architecture involves two models - a domain entity in the domain layer and a database entity in the infrastructure layer. Therefore, layers must map their models when transitioning to a higher layer or receiving data in the lower layer, increasing implementation overhead. This problem does not occur in multilayer architecture, where models are defined in the higher layer to which the lower layer has access.


**What to Choose?**

The appropriate architecture choice depends on the project's complexity and business requirements. Multilayer architecture is simpler to implement, while clean architecture provides better separation of responsibilities and is more scalable. Remember, architecture is like clothing - each project needs an individual approach to feel comfortable and work effectively.

Depending on our project's needs and complexity, we can adapt it. Clean architecture and multilayer (and others not mentioned here) are known ways to handle common issues such as maintainability, testability, and scalability. There is nothing to prevent us from modifying existing solutions and adapting them to our needs. A good idea is to identify the responsibilities defined by GRASP in our code and architecture. This way, deciding how to structure the code will be easier. Additionally, it is worth familiarizing yourself with other GRASP principles that can help us make decisions in grouping and separating responsibilities or prepare us for change.

large_blog-duraj part 3_cover_high.jpg

medium_blog-duraj part 3_cover_high.jpg

small_blog-duraj part 3_cover_high.jpg

thumbnail_blog-duraj part 3_cover_high.jpg

blog-duraj part 3_cover_high.jpg

Backend Architecture on Frontend Part 3


Frontend Engineering

UX/UI Design

Research & Discovery

AI For Your Business

Services

Case Studies

Career

About us

Blog

#### **Though, there was a problem...**
Some time ago, while working on one of the tasks in the project, I got to the stage where I had to write a test. I am aware that someone now could say that I should start with tests at the beginning. Why didn't I? Because some parts of the code already existed (and were not tested), and I wanted to be sure that my changes would not mess with what I found. This decision was ultimately aimed at overall improvement of the quality and testability of this part of the application.

The application remained uncooperative and did not want to perform, despite the fact that in my subjective opinion the quality of the found code was not so bad. Of course, I would find a few things that I would like to refactor, but despite the lack of testing, the code seemed *testable*. And I was not mistaken. After about 40 minutes I had a very decent *test suite* written, that covered a few existing and new cases. As an engineer, I was satisfied, but still something was bothering me. So I took two steps back and looked at my work again. I was troubled by a few questions. Why was the code so reluctant to be tested, despite its apparent testability? Did I spend enough time on these tests?  What's more, I started to wonder if what I tested actually gives me enough feedback in the case of subsequent changes to the system? It was definitely a topic worth exploring a bit more!


#### **Application Architecture On Her Testesty's (Secret) Service**
For the sake of simplicity, let's assume that the code architecture is primarily the way a code is organized. Of course, this does not only apply to the folders structure, but above all, what responsibilities are met by its individual parts. In the case with my project, we talk about striving to meet the demands of Clean Architecture, also known as Hexagonal, Ports and Adapters or even as Onion, although the latter name has not really caught on. Within this architecture, we distinguish three layers:

1. Infrastructure level - where we communicate with the outside world and use external dependencies (e.g. attached libraries and packages),

2. Application level - where the operational part of our application should be happening,

3. Domain level - where key decisions should be made, e.g. about changing the state of the application.


An interesting property that we should look for in such architecture is the range of visibility of each of these layers. The domain only sees itself and cannot access other layers. The application level has knowledge of the domain and itself. Infrastructure, in turn, sees everything - both from above and below. This mindset forces the developer to always include dependencies from the infrastructure layer to the application layer. We can say that we insert the dependencies from the bottom or, as in the case of the visualization characteristic of this architecture - from the outside to the inside.

![ ](\uploads\Blog_artykul_TestingAggregates_LukaszD_02_1r3nE0JHqmRUOI6znpMU7u.jpg)
##### Graph 1. Visualization of Clean Architecture, own diagram (Domain, App/application, Infrastructure)
We also aim for such architecture when we try to design our application according to DDD (Domain Driven Design) methodology. The system I was working with was definitely heading in DDD direction, although there were still a lot of things to do. That is why ideas derived from DDD appeared in the code, such as entities, value objects, or repositories. This blog-post is not intended to explain what DDD is and what concepts it consists of, but for a further understanding of the whole context, let's adopt such simplified definitions for a few of the terms that I used:

- Entity - it is an object with an identity that represents some model. For example, a user that we can uniquely identify. This model, however, unlike the typical approach containing mainly anemic entities, apart from data, also has methods that allow you to perform some action on this object.

- Value object  - this is an object that has no identity. A perfect example is the representation of money. However, unlike a simple data structure, it may also have some logic, e.g. related to validation, different representation or comparison.

- Repository - it is an object that allows us to perform database operations. However, it should provide a high-level API to not reveal implementation details.


It seems Uncle Bob would have accepted that. However, how could such architecture help us in any way in testing? What layer should we test the most? What should such tests look like? Unfortunately, it seems that the very concept of this architecture does not answer those questions. So let's try to ask a slightly different one. What makes a test easy to write, and what makes it difficult or even impossible?

#### **White or black?**
One popular pattern for writing unit tests is the 3xA rule:

- Arrange - prepare the application so that it can be tested,

- Act - perform an action,

- Assert - check and test if the result of the action is consistent with your predictions.


After analyzing the tests I wrote for the project I noticed that the Arrange stage, i.e. test preparation, was the most time consuming part. The very implementation of the action and test usually came down to one or two lines of code, but preparation took even a dozen or so. Besides, I had a strong feeling that I needed to go too deep into the implementation to know how to test a given piece of code.

Let's look at the following code snippet:

``Code 1: Implementation of the Calculator class``



Now let's try to test this code:

``Code 2: Tests for the Calculator class``



The code shows a very simple implementation of a calculator with two methods for dividing and adding. Very often, such samples are used to show an example of testing an application.



In each test case, I started with a comment of the part of the Arrange, Act and Assert sections. You will notice that these sections are very short and concise. Each test consists of 3 lines, one for each section. However, I would like to highlight one important thing that seems to be overlooked or not sufficiently resonant in such examples. These tests are very simple and quick to write. You could say that we are testing a very simple sample class, but actually such cases rarely occur in the real world. One could even say that these tests are detached from reality. But let's consider what, apart from this uncomplicated example, makes these tests so simple:

- explicitly defined contract in the form of the *CalculatorInterface* interface,

- the *Calculator* class has no dependencies,

- methods have all the information to be able to perform the requested action,

- there is a constant relationship between the input parameters and the return value.



It can be clearly stated that by looking at the methods of this class, we are able to say what their behavior is and what results we can expect. Thanks to this, knowledge of the internal implementation is not required and we could actually write tests based only on the methods specified in the *CalculatorInterface* interface. Tests with these properties are called *blackbox tests*. The black box test is the simplest type of test that makes it much easier to check your application. However, we rarely test simple calculators in our lives. So let's try to discuss a slightly more complex case.

``Code 3: Currency exchange service``



The purpose of this class is to convert the value of one currency to another. It has a dependency in the form of a repository returning the current exchange rate. The specific implementation of this repository, as part of our Clean Architecture, should be placed at the infrastructure level. In our case, this type of service belongs to the application layer. In the domain layer, in turn, there will be concepts presented as value objects, such as *Currency*, *Money* or *ExchangeRate*. Let's try to add tests for this class.



``Code 4: Tests for the CurrencyExchangeService class``



You can see at first sight that this test is much more complicated. What’s more, the number of lines of the test is bigger than the test code itself! This one test took me a lot more time than the 3 previous ones for the Calculator class combined. The test itself is not complicated, although some intellectual effort was required to have it prepared. It's worth noting that the *Arrange* section contains the most lines of code. As the *CurrencyExchangeService* class has an external dependency, it had to be replaced with an object of the class pretending to be a real repository. Such an object is called *Test Double* (the name refers to the term *Stunt Double*, i.e. a stuntman who replaces an actor in dangerous scenes of the movie). It is supposed to replace the original object on which it will be possible to call the necessary methods and return the previously prepared data. This is to ensure the repeatability of the test execution and to cut off the true dependencies in order to be able to test the code in isolation. In this particular case, I used a *Mock-type* test double, which allows you to verify whether a given method was used during the test. It also allows you to define what parameters the method should expect and the value to be returned.


In comparison to the previous example, in order to call and test the *exchange* method, I needed to know the internal implementation of the *CurrencyExchangeService* class. I needed to know that this method would call the *getExchangeRate* method inside and what value this method would give in return. Creating a test double complicated the process of writing the test. It is also not as transparent as the tests for the *Calculator* class. Tests where implementation knowledge is required are called *whitebox* tests. What is more interesting, almost all the tests I wrote and were dedicated to the problem described at the beginning of this article were *white box tests*. The tested classes had a large number of dependencies, so the *Arrange* stage first included the instance of many test doubles, which made the whole testing process difficult. I will also mention that the preparation of these test double files was extremely boring and required a thorough code review (as these tests were written in the form of TAD - *Test After Development*) in search of a specific use of them. It can be clearly stated that the white-box tests are much more difficult to write, although at the moment it seems that they are still much more “real life-like” than the black-box tests. Ideally, we should only be able to test the functionality with black-box testing. Then the question arises how to do it and how would our application architecture help us? Let's look at one more example and try to transform it to answer these questions.

#### **A classic. Testing the cart**
``Code 5: The CartService class``




In the presented section of the code, we have the part responsible for using the coupon with a percentage discount on the items added to the shopping cart. The *applyDiscountHandler* method takes a command (that is, an action request) and gets an instance of the current cart and finds the coupon in the database. Then it applies the coupon according to the business rules, saves the changed cart and blocks the coupon so that it cannot be used again. The code structure and dependencies are distributed within Clean Architecture.

![ ](\uploads\Blog_artykul_TestingAggregates_LukaszD_04_3CbAXJz8YLyGPyQgnyXlxZ.jpg)
##### 
Graph 2. Code structure of the Cart module
We can list the characteristic blocks from which we build the application using DDD design. Let us think about how we could test this method. The *CartService* class has 3 dependencies. Two for the repositories for the cart and coupons and one for the service for broadcasting events (event - something important happened in the system). This means that at first we would have to create mocks for these dependencies. Then we should check what methods are used (how many times, with what parameters and what they return) and set them accordingly. The key action we are trying to perform is actually changing the state of the *Cart* object. However, the *CartService* class does not return an instance of this class in any way. Verification of its condition would also have to be done with a *mock*. Definitely,  It would be a white box test. What's more, the code doesn't make it easy for us by returning nothing, which would require workarounds and tricks to make it work. This kind of test would be neither easy to write nor read (and we need to remember that tests are the best documentation!). At this point, we should have a feeling that something is wrong with our code. Let's try to refactor our code to make our tests a little easier to write and a little more readable.  So what is wrong with the code presented?

- The method definitely breaks the SRP (*Single Responsibility Principle*) principle and does too much - so it would be good to separate the operations on the coupon and the cart from each other.

- The business logic of the discount calculation rules leaked from the domain to the application site. The application layer is responsible for the operational part of the program. It should not make business decisions.

- Two different business logic are mixed up here. Logic of coupon management and blocking, and logic of the cart calculation.


First, let's deal with the separation of responsibilities. 

``Code 6: DiscountService class``



We have created a new class that deals only with the validation and coupon usage. On the found coupon, we call the *useDiscount* method, which returns the event informing about the change of the coupon state. Let's take a look at the *Discount* class.

``Code 7: Discount class``



*The Discount* class has no dependencies. All the information required to make the state change decision was provided in the initialization stage. So we have led to a situation where we can test our business logic with a ... black-box test!

``Code 8: Tests for class Discount``



Definitely, the test of our business logic looks much neater than the test of the currency conversion site and it took a lot less time to write it. Thanks to the returned events, we can examine the connections between the input parameters and the output parameters of the method. The use of the concept of events is also not accidental. By events, we mean a change of state that is significant for the system. This is also what happened in this case. Then, within *DiscountService*, we do two things with the event:

- We save the change - depending on the system architecture, we can save this event in our database. The sum of all events (i.e. changes in state) on an object will always give us its current state. On the other hand, in a system where these historical state changes are irrelevant, we can update the state of the object directly. In the latter case, however, it is good to transfer a new, consistent instance of the object being provided inside the event.

- We publish an event - thanks to this, other objects listening to specific events can take their own actions. This is how we make it possible to apply our coupon to the cart.


``Code 9: The CartService class``



The *DiscountCouponUsedEvent* event caused the *applyDiscountHandler* method to be called on a *CartService* object. This event brings the necessary information that we need to apply to our shopping cart. As you can see, there is no need to provide the entire discount object, only information about the discount type (*DiscountType*) and discount percentage (*DiscountPercentage*).

``Code 10: Cart Class`` 




Again, the *Cart* class has all the information required to apply the discount and returns an event as a result of calling the *applyDiscount* method. Then we persist in this event and publish it. This approach creates a cause and effect chain that is very easy to follow and understand. The *Cart* type tests will also be black box tests. However, the question arises, what about the *CartService* and *DiscountService* classes? Both have dependencies, so testing them forces us to do white-box testing. At this point, I would like to highlight the responsibilities of these services. Their task is to:

- preparation of our object (*Cart/Discount*),

- calling the appropriate method with appropriate parameters,

- calling actions aimed at preserving and publishing events.



Isn't that a bit like the *Arrange, Act, Assert* pattern? We have to answer the question, what would we really like to test in these classes? There seems to be no point in testing them, as the essence of their responsibility is actually triggering our business logic. So these would be the same tests we wrote for the *Discount* and *Cart* classes, but wrapped in a complicated structure of stubs and mocks. Therefore, integration tests, not unit tests, would make much more sense here.

#### **So where are these aggregates?**
The title of this article promised the aggregates, and I still haven't mentioned anything about them. This is a deliberate case, as it seems to me that this topic is not fully understood by many programmers. In the given example, all we did is refactor a little and reorganize our code. This allowed us to bring it to a stage where we were able to test it with a much simpler black-box testing method. As a result, our *Cart* and *Discount* classes have acquired some properties that they did not have before, namely:

___
**they have all the information required to make a business decision**

___
As a result, they can protect data with consistent rules and make state change decisions without having to ask other parts of the system for additional conditions. Let's add to this supplementary conditions that do not result directly from the code:

- *Cart* and *Discount* class objects should always be created in whole extend (all required data should be loaded),

- state changes should be persisted atomically (i.e. always all together),

- only the *Cart* and *Discount* classes can modify their state - no other part of the system can do so.



By adding these few additional conditions, it turns out that our *Cart* and *Discount* classes are technically... aggregates in the sense of the DDD. More precisely, the roots of their aggregates. To illustrate this better, take a look at how I reorganized the directory structure of our component.

![ ](\uploads\Blog_artykul_TestingAggregates_LukaszD_05_5EIfawNNSZ2LZx9zqPsdHr.jpg)
##### Graph 3. Cart module structure containing aggregates
The Domain class contains 3 catalogs: *Commons*, which contains common concepts, and *Cart* and *Discount*, where our aggregates are located. I highlighted their roots in blue, i.e. classes that constitute a public interface for interacting with the aggregate. It seems to me that such a presentation of this concept can be much more accessible, because it not only shows us the benefits of a much better testability of our code, but also one of the ways in which we are able to extract aggregates from our system. Of course, there are much better and more appropriate tools for this (e.g. process and tactical sessions in Event Storming), but even if we do not know these concepts, we can improve our applications in the way presented. 

#### **Who is your boss?**
In conclusion, I would like to present a certain analogy that comes to my mind when I think about the responsibilities of clean architecture. This analogy can be helpful when we are forced to decide how we should organize our application code.

![ ](\uploads\Blog_artykul_TestingAggregates_LukaszD_03_2lCBUwq9BZwf1P03b5469X.jpg)
##### Graph 4. Analogy of Clean Architecture to Organization, own diagram

Imagine your company has three levels:

1. The boss - the decision-maker

2. Middle-level manager

3. Employees


The responsibility of a middle-level manager is to execute the plan provided by the decision-making person. He does not do it by himself, but delegates work to employees. Employees do it physically. Moreover, the manager is responsible for providing the data the boss needs to make specific decisions. The preparation of these data is also delegated to employees, but the manager may also format or organize them differently before handing them over to the boss. In a large organization, the boss very often does not even know his employees. The data is provided to him by the manager, so there is no need to ask and search for data from the lowest-level employees. He is also not interested in the way the assigned tasks are performed.

Our application structure works similarly. The application layer orders the physical download and preparation of data for specific instances in the infrastructure layer, which retrieve it from the database and return our aggregate root. Then the parameters are called and passed to the aggregate method, which makes the decision about the state change already in the domain layer. This decision is returned by event to the application layer, which is then delegated back to the infrastructure layer for persistence and publication.

#### **Try it yourself!**
As part of this article, I also created an implementation of this solution. As you may have noticed, not everything I wrote about has been tested. What's more, the infrastructure layer has not been presented here in any way, which in our case can be completely replaced by tests. If you would like to practice, fork the codebase repository and try to extend the existing tests, modify the *CurrencyExchangeService* class the same way I did with the *CartService* class. Suggest your own solutions and share your implementation with everyone in the comments. I am curious about your opinion on how you understand the presented topic and ideas for implementation.

The blog post was created as a translation of a "Testowanie agregatów, czyli architektura wspierająca testowanie" entry on [**devkick.pl**](http://devkick.pl/testowanie-agregatow-czyli-architektura-wspierajaca-testowanie/)
, written by Łukasz Duraj. 

GitHub - [**lukasz-devkick**](https://github.com/lukasz-devkick)
**/**[**aggregates.testing**](https://github.com/lukasz-devkick/aggregates.testing)




small_Blog_artykul_TestingAggregates_LukaszD_cover_high.png

thumbnail_Blog_artykul_TestingAggregates_LukaszD_cover_high.png

Blog_artykul_TestingAggregates_LukaszD_cover_high.png

Testing Aggregates

#### The Story Repeats Itself

When I started my programming journey, I was simply a Web Developer. I was responsible for both frontend and backend parts, communication between them, and often for deployment and maintenance as well. Over time, however, these roles began to specialize, and people started focusing only on certain parts of the development process. This specialization was necessary since the complexity of systems has been growing, making it harder to understand, develop, and maintain the entire software stack. This complexity stems from more than just business logic but also from the myriad of technologies, tools, libraries, and frameworks. However, it turns out that having many specialized professionals is sometimes not cost-effective for projects of a certain scale. This gap has been filled by frameworks like Remix and Next.js, which are full-stack frameworks offering both frontend and backend programming capabilities.

#### However, Here Lies the Problem…

The cycle has yet to come full circle. The emphasis has shifted. In the past, frontend applications were secondary to backend applications. The backend would generate HTML for the frontend, and over time, with the advent of browser scripts, this trend started to reverse. In many contemporary applications, the focus is now on the frontend. This shift depends on the type of project and the complexity of its components. Sometimes, we deal with a simple interface and a complex API, while other times, both are equally complex or simple. However, the problem that frameworks like Next.js solve is when we have a complex interface and a simple API, which can be compared to a data repository. These frameworks allow us to quickly program a complex frontend application and the necessary backend application. In such cases, it's advantageous to have a developer who can handle both sides, saving a lot of time and money by avoiding the need to create a separate API. In this scenario, a frontend developer is the obvious choice. However, with specialization towards the frontend, backend skills are often neglected, resulting in a backend that becomes unmanageable, with complexity growing and resembling spaghetti code, while the frontend code remains clean and consistent.

#### Why Does This Happen?

Frontend applications have a different nature compared to backend applications. The architecture is inherited from available frameworks and libraries, implicitly guiding the developer. Although this approach can backfire in the long run and become unmanageable, it's better than having no architecture at all, especially when we are unsure how to design one sensibly. This is the situation we face on the backend side with Next.js or Remix. These frameworks offer us an entry point to the backend, automating communication via AJAX so we don't have to manually integrate it. However, they don't provide us with a structure within which we can operate.

#### Let's Introduce Some Architecture!

Since the framework doesn't enforce it, we should ensure we have an architecture that structures our code. Our basis for consideration will be GRASP, or General Responsibility Assignment Software Patterns. It contains a set of 9 basic principles and responsibilities that we should apply in our code. For our purposes, let's select 4 responsibilities:

- **Information Expert** - the object with all the information needed to perform a certain task.
- **Controller** - the object that controls the flow of work.
- **Pure Fabrication** - the object that performs tasks that are not part of the domain.
- **Creator** - the object that creates other objects.

These 4 types of objects outline an obvious division that we can try to implement in our application:

- **Domain part**, which will represent the concepts of our client's business. We can also think of it as concepts that could exist without the IT system, e.g., instead of a product catalog, we have a flyer sent by mail to the customer's mailbox.
- **Technical part**, which is required to handle the domain part and exists solely for the IT system's needs.


First, we should identify the responsibilities above in our code and check if they are mixed together. This way, we will separate the technical part from the business logic, laying the foundation for further dividing our architecture into layers.


#### What Can Be Done?

The lack of enforced architecture often leads to a haphazard structure, resulting in code that is hard to maintain, untested, and challenging to develop. In the following article, we will look at what to pay attention to when creating an architecture: not to invent our own architectures from known templates, but to adapt them to our real needs and make the first architectural decisions.

large_blog_cover_high.jpg

medium_blog_cover_high.jpg

small_blog_cover_high.jpg

thumbnail_blog_cover_high.jpg

blog_cover_high.jpg

Backend Architecture on Frontend Part 1

In the previous article, we outlined the problem of lacking enforced architecture in frontend frameworks that also allow frontend developers to write backend code. In this article, we will look at what to pay attention to in order to start structuring your code at a low cost. However, before we delve into application architecture, it's worth making a few architectural decisions to shape our application.

#### Separating Queries from Commands

A common issue that causes code clutter and reduces maintainability is overly large objects. By "overly large," I mean objects that hold too much information simultaneously. The reason objects hold too much data is often due to read operations. Some data is needed to make decisions, while the rest is just to display to the user. It's beneficial to separate these two situations. Even if we store the data in a single database table, we should create two independent models: one for reading and another one for making decisions and updating.

To achieve this, we can apply the CQS (Command Query Separation) or CQRS (Command Query Responsibility Segregation) patterns in our code. They both assume the separation of reading (Query) from writing (Command). Queries never modify data, and Commands do not return data. The difference lies in implementation: in CQS, we might have a single service with Command and Query methods, while in CQRS, we have entirely separate services or even microservices for both types.

In the provided example, it might seem that not separating queries from commands generates less code. However, this is a very superficial conclusion. By using CQS/CQRS, we slim down our write models and can create more flexible queries for our read models. Adding additional read data does not affect our commands and tests, making them more resilient to changes. We also avoid multiple places for reading or writing the same model, making the code more reusable.
![blog-code 1.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_code_1_a4980c7691.jpg)

_Code: Examples of CQS and CQRS. The repositories used are examples of Pure Fabrication from GRASP. They can also call Creator underneath, which instantiates returned objects._


#### Rich vs. Anemic Entities

Another important aspect is the approach to our data entities. Typically, there are two types:
- **Rich Entities** - contain both data and behaviors operating on that data. They do not have getters and setters. Behavior methods change the object's state and enforce business rules in one place. Rich entities are an excellent example of Information Expert.
- **Anemic Entities** - contain only data, along with getters and setters. Business logic is implemented in separate services that operate on these entities, change their state, and enforce business rules.

Existing backend frameworks often suggest the second approach, but using rich entities is a much better solution. Key behaviors, rules, and data are represented in one place, preventing entity bloat. In both cases, however, we should remember that entities should be as small as possible, containing only the data needed for specific decisions. A much better place for using anemic entities is DTOs (Data Transfer Objects), used for data transport between layers and modules, or objects for creating views (e.g., response from a Controller).

![blog-code 2.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_code_2_2fea35e4d6.jpg)

_Code: Example of an anemic entity with a service handling it._

![blog-code 3.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_code_3_e81ee58004.jpg)
_Code: Example of a rich entity with its use in a specific use case. AddOrderItemUseCase is an example of a Controller from GRASP._

#### Modules vs. Layers

Two techniques that help us divide our code into more manageable parts are modularization and layer division. An application module is more extensive and can be treated as a separate subprogram with its own application architecture (i.e., one that divides responsibilities according to layers) and its own API. Modularization is an individual, more significant topic, so we'll focus only on application architecture in this article. The following article will consider the two most popular application architectures: three-layer architecture and clean architecture. Regardless of the architecture type, it's important to remember that layers always have a unidirectional relationship, meaning the lower layer knows about the higher layer, but the higher does not know about the lower. This is crucial to avoid creating spaghetti code. Remember, the difference between a mere directory structure and layers primarily lies in respecting their relationship boundaries.

#### Did I Define the Layer Boundaries Correctly?

A good question is whether the boundaries I defined between layers are indeed boundaries. To this end, it's worth conducting a thought experiment. If I remove the lower layer and instead insert tests that call my layer, will the code of my layer still perform its tasks? If not, and there are missing dependencies to the lower layer, it means the boundary between layers is not respected, and our code will slowly degrade. Another more technical method is to use a simple architectural test that checks if there are imports to the lower layer's directory within the files of a given directory.

#### Application Architecture

Identifying and assigning responsibilities to objects in our code and determining the approach to our read and write entities is the basis for adequately dividing it into layers. In the next part, we will present the types of application architecture and how they interact with the concepts presented in this article. We will also identify the essential responsibilities of GRASP within the individual layers of known architectures.


Backend Architecture on Frontend Part 3

Łukasz

Testing Aggregates

Łukasz

Backend Architecture on Frontend Part 1

Łukasz

Backend Architecture on Frontend Part 2

Łukasz

GET IN TOUCH