Functionality Driven Design: A Paradigm Shift in Software Architecture
We have observed software architecture trends and methodologies evolve through various phases, with design, sketches, and concepts frequently emerging, dissolving, and reemerging. There was a time when monolithic architectures dominated, followed by the era of microkernel architecture with its plugin-based features. Now, we are in the age of microservices. However, ‘microservices’ has become such a buzzword that engineers and architects often implement it without fully understanding the underlying concept, its topological complexity, and the extensive infrastructure, costs, and insights required for sustainable implementation.
This misunderstanding has led to the deployment of microservices in systems where they are not truly necessary, continuing a pattern where even the smallest system concepts are implemented using microservices regardless of their actual need. Startups, even those with minimal funding, are adopting a microservices architecture without fully considering the significant costs and complexity required for such systems to operate effectively. Implementing microservices requires the integration, analysis, logging, and monitoring of multiple components, ideas, concepts, and theories to function at a high level. While it remains an important and crucial architecture, I am not a strong proponent of using this architecture in certain situations, especially where cost is a limiting factor. Despite its benefits like scalability, reliability, and fault tolerance, microservices address many issues that their predecessors couldn’t.
Microservices often follow a Domain Driven Design (DDD) philosophy, a software development approach centered around a domain, with the practice of equating a domain to a service in a high-level system. However, cloud computing has introduced several new concepts that were not feasible in the era of manually managed data centers. One such methodology is serverless computing, where the infrastructure is abstracted, and users pay only for the resources they use. This has inspired what I call Functionality Driven Design (FDD). I believe microservices can be further decoupled from domains to functionalities while using abstracted servers, improving scalability, cost-effectiveness, and simplicity.
FDD focuses on the specific functionalities required by a system rather than on broader domain models. In FDD, containers are replaced with serverless pods, each mapped to a specific functionality like an API or message queue. These services can be scaled based on demand and don’t need to run indefinitely, addressing the cost issues of a microservices architecture. This approach is particularly suited for startups facing unpredictable demands and limited budgets. Serverless technologies, operating on a pay-as-you-go model, are ideal for such operations. FDD also provides a platform for startups to build an MVP with only the necessary functionalities, leading to faster market entry.
Functionality Driven Design Concepts
One might ask several questions about Functionality Driven Design (FDD): ‘What exactly is FDD?’, ‘How does it differ from Domain Driven Design (DDD)?’, and ‘How will this new concept be utilised in practice?’. All these questions will be answered in this section.
Functionality Driven Design (FDD) is a software architecture philosophy which focuses on the distinct and relevant functionality required in a system rather than the broader service categories of domain models. FFD doesn’t only focus on the distinct and unique function but also the relevant ones. FDD is a minimalist approach which allows architects to test, refine and change functionality without significant overhead. It operates on a couple of principles:
Minimalism: Functionality Driven Design (FDD) is a minimalist at its core, every decision made in this paradigm has to be essential, there is no room for extravagance in this design approach. Every functionality which is integrated into this paradigm has to be compulsory and necessary, this concept is essential cause it allows organisations to reach the market in faster cycles and it also gives cooperation a playground to test, refine and tweak functionalities of their solutions without any operational overhead or cost.
Responsiveness: FDD relies on responsiveness which are extremely critical for startups and dynamic environments which is the rationale for the use of server-less technologies, server-less technologies are very dynamic and operate using a Pay as you go model, this is extremely critical for co-operations with limited budgets as they would only need to pay for the services which are utilised. In a typical micro-services architecture utilising the Domain Driven Design (DDD), containers are typically mapped to a domain which are constantly running and there are often multiple instances of this containers which could be potentially hosted on AWS EC2 or other cloud hosting technologies. Although, this method can be very responsive with auto scaling tools provided by cloud platforms, there can be a lot of unnecessary cost accrued from idle resources.
Independence & Decoupling: Functionality Driven Design (FDD) follows the same principles of independence and decoupling which are evident in Domain Driven Design (DDD). This independence would allow easier maintenance, updates and scalability of individual functions without impacting the whole system. In the context of micro-services, a independent deployable unit typically represents a domain which differs from modularity which FDD follows. FDD breaks down domains into functionality. Functionality refers to whether a design works and helps the users meet their goals and needs. To illustrate the concept of “Independence & Decoupling” in Functionality Driven Design, Imagine a software system for an online bookstore. In DDD, the system might be divided into different domains like Inventory Management, Order Processing, User Accounts, and Payment Processing. Each of these domains is independent and loosely coupled, meaning changes in one Domain, like Payment Processing, don’t necessary affect others, like Inventory Management.
Now applying Functionality Driven Design (FDD) to this, we further break down these domains into smaller, more specific functionalities. For instance, the Inventory Management domain could be divided into functionalities like Book Catalog Management, Stock Checking, and Reorder Alerts. This independence is crucial for maintenance, updates, and scalability.
In the context of micro-services, each of these functionalities could be developed as a separate, independently deployable unit. This differs from the broader domain separation in DDD. In FDD, the focus is on the granularity of functions and their operational independence, leading to a system where changes and updates can be made in a more agile and less risky manner.
By breaking down domains into specific functionalities, FDD ensures that each part of the system is focused on what it needs to do (its functionality), works effectively, and meets user goals and needs without being overly entangled with other parts of the system. This can extend the scalability which is offered by micro-services.
The philosophy of Functionality Driven Design (FDD) rests on three principles which were discussed above which are minimalism, responsiveness and independence/decoupling. These core fundamental concepts allow faster time to market, quicker development cycles and easier maintainability. Domain Driven Design (DDD) allows co-operations to map domains to the best tools.
In conclusion, Functionality Driven Design (FDD) represents a significant shift in software architecture, moving away from the broader domain-centric approach of Domain Driven Design (DDD) towards a more granular, functionality-focused methodology. By emphasizing minimalism, responsiveness, and independence/decoupling, FDD aligns well with the dynamic needs of startups and businesses operating under constraints of budget and time. It leverages serverless technologies to provide a cost-effective and scalable solution, enabling organizations to deploy only the necessary functionalities with minimal overhead.
FDD’s minimalist approach ensures that every integrated functionality is essential, reducing operational costs and enabling quicker market entry. Its responsiveness, facilitated by serverless computing, aligns with the financial and operational realities of companies with limited budgets, paying only for the resources used. The independence and decoupling principle in FDD allow for easier maintenance and scalability, as each functionality is developed as a separate, independently deployable unit, reducing the risk and complexity associated with updates and changes.
This philosophy, therefore, offers a viable alternative to traditional models, particularly in an era where agility, cost-effectiveness, and rapid deployment are crucial. FDD could be the answer for startups and organisations looking to innovate swiftly and efficiently, providing a framework that aligns with the evolving landscape of cloud computing and the ever-changing demands of the tech industry.
rustian ⚡️
