by Michal Dorner

We have been building multi-layered applications for so long it becomes the de-facto standard pattern. The main idea is to split the application into at least three distinct layers: Presentation, Business and Data access.

In theory, this pattern provides clear separations of concerns. By segregating an application into layers, developers acquire the option of modifying a specific layer, instead of reworking the entire application. Unfortunately, it turns out this doesn’t reflect reality.

As the application grows, the layers grow with it until they become monoliths of their own. Each layer has a direct dependency on a lower layer and an invisible semantic dependency on the upper layer. The actual implementation of every layer is driven be requirements of the upper layer. In the end, business aspects are spread everywhere. Therefore, implementing a business feature almost always requires modifying every layer in the system. Our code is localised around technology aspects while the axis of changes is usually around business aspects. This makes both maintenance and extension of the system much harder.

Feature slices

In contrast to the n-tier architecture, the idea around vertical (feature) slices is to localise code around business aspects. Layers representing physical interfaces like API or database schema are preserved. Rest is split into slices where each slice should support a single business feature. Important is to minimise the coupling between slices and maximise coupling within a slice. In some extent this is similar to the microservice architecture, however, the application is still a single deployment unit.

Conceptual differences between DDD style n-tier architecture, feature slices and microservices are illustrated in the following figure:

feature slices infographics

 

Microservice architecture is using the same principle but introduces also a physical separation between feature slices. This is crucial for scaling or independent development and deployment of individual services. Along with these advantages come a cost of increased complexity in deployment, versioning and code sharing. Therefore, if you don’t need any of the additional benefits of microservices it’s better to keep the monolithic approach with internal feature slices.

Code scalability

Term scalability in software engineering usually refers to usage scalability (e.g. number of requests system can handle) or scalability over time (e.g. amount of aggregated data system can handle). However, there is also another commonly forgotten aspect – scalability of the code itself. It means how long the system can be extended and modified before the codebase becomes unmaintainable.
Feature slices isolate ever-changing business requirements into separate modules. This significantly helps with keeping the overall structure of the system reasonable. Feature slices basically pushes for single responsibility principle and open-closed principle applied on an application level.

CQRS, Transaction Scripts and DDD

Feature slices are a natural fit for request/response applications like web APIs. A good approach is to treat each request as a distinct use case. This plays very well with the CQRS pattern – HTTP GET request are queries while HTTP POST, PUT and DELETE requests are commands. Each command/query can then decide for itself how to best fulfil the requirements.

For most cases, they can be implemented as transaction scripts. Transaction scripts organise logic primarily as a single procedure without additional domain abstractions. As Martin Fowler wrote in his book “Framework Design Guidelines: Domain Logic Patterns”:

The glory of the Transaction Script is its simplicity. Organising logic this way is natural for applications with only a small amount of logic, and it involves very little overhead either in performance or in understanding.

For really complex cases where a transaction script would be hard to reason about it’s still possible to use some different approach. A common solution is to use Domain Driven Design (DDD). However, DDD again implies layers and all the disadvantages mentioned earlier. Even Microsoft recommends that DDD should be applied only to complex domains where the model and the linguistic processes provide clear benefits in the communication and in the formulation of a common understanding of the domain.

Summary

Layered architecture and Domain Driven Design are here for a long time. Now it’s time to at least admit they no longer deserve the status of a de-facto standard for enterprise software designs.

On the other side, there is a lot of hype regarding the microservice architecture. While it solves many problems it also brings a new one.

An alternative is to use feature slices. It solves many of the issues related to layered architecture while it doesn’t bring the additional complexity of microservices.

News from ERNI

In our newsroom, you find all our articles, blogs and series entries in one place.

  • 06.12.2023.
    Newsroom

    Streamlining software development: The journey from multiple to unified requirements management tools

    Productivity in software development is slowed down by managing specifications across various requirements management (RM) tools. Although moving to a single, updated RM tool involves an upfront investment, the long-term benefits are considerable. These include increased process efficiency, enhanced collaboration, superior traceability, improved software specification quality, cost reductions, scalability and better integration with other RM tools, among others.

  • 22.11.2023.
    Newsroom

    Recognising trends: An insight into regression analysis

    Data plays a very important role in every area of a company. When it comes to data, a distinction is made primarily between operational data and dispositive data. Operational data play an important role, especially in day-to-day business. However, they are not nearly as relevant as dispositive data. This is because these data are collected over a longer period of time and provide an initial insight into the history or the past.

  • 08.11.2023.
    Newsroom

    Why do we need digital transformation for medical devices?

    For hospitals, it is not up for discussion as to whether they want to digitalise. The increasing age of the population in western countries and the progressive shortage of medical professionals mean that without digitalisation, the healthcare system will not be able to provide the quality that patients want in the future.

  • 25.10.2023.
    Newsroom

    Mastering the challenges of mobile app testing: Strategies for efficient quality assurance

    Discover the unique challenges faced in testing mobile applications and learn how to overcome them effectively. From selecting suitable devices and operating systems to leveraging cloud-based test platforms, test automation and emulators, this article provides seven essential strategies for optimising your mobile app testing process.

  • 11.10.2023.
    Newsroom

    Incorporating classical requirements engineering methods in agile software development for a laboratory automation system

    Traditional agile methodologies can sometimes struggle to accommodate the complexity and regulatory requirements of laboratory automation systems, leading to misalignment with stakeholder needs, scope creep, and potential delays. The lack of comprehensive requirements documentation can result in ambiguous expectations and hinder effective communication among cross-functional teams.

  • 27.09.2023.
    Newsroom

    Unveiling the power of data: Part III – Navigating challenges and harnessing insights in data-driven projects

    Transforming an idea into a successful machine learning (ML)-based product involves navigating various challenges. In this final part of our series, we delve into two crucial aspects: ensuring 24/7 operation of the product and prioritising user experience (UX).

  • 13.09.2023.
    Newsroom

    Exploring Language Models: An overview of LLMs and their practical implementation

    Generative AI models have recently amazed with unprecedented outputs, such as hyper-realistic images, diverse music, coherent texts, and synthetic videos, sparking excitement. Despite this progress, addressing ethical and societal concerns is crucial for responsible and beneficial utilization, guarding against issues like misinformation and manipulation in this AI-powered creative era.

  • 01.09.2023.
    Newsroom

    Peter Zuber becomes the new Managing Director of ERNI Switzerland

    ERNI is setting an agenda for growth and innovation with the appointment of Peter Zuber as Managing Director of the Swiss business unit. With his previous experience and expertise, he will further expand the positioning of ERNI Switzerland, as a leading consulting firm for software development and digital innovation.