In the ever-growing software ecosystem, successful products need to have great performance, security, maintainability and usability. For the people who deliver those products, quality assurance, time to market and cost matter most. They sometimes push security-related tasks to the side. After all, time is tight. It doesn’t matter if the system is secure if features the users need are not there. So, how do you build security into the pipeline in a way that keeps it important? Domain-driven design provides a roadmap. Take an in-depth look at how it works. 

With the traditional approach, the security review identifies severe vulnerabilities to address before production. This can set your project back by a few weeks, or maybe even months. That, in turn, results in lost revenue. To create secure software efficiently and effortlessly, it is important to focus more on security by design rather than leaving it as an afterthought.

Starting with the Basics of Design

To understand domain-driven design, we need to answer another question first: What is design?

Well, the developers writing code pay careful attention to represent business logic. That’s the part that makes the product unique, builds code explicitly and makes the product easy to maintain. While modeling the business domain, developers spend a considerable amount of time evolving and refining the domain model and how they will represent it in code. For example, they consider aspects such as readability or performance, based on preferences, and decide how to write the code in that statement. Based on experience and knowledge, they make choices that match the software built. These choices are part of what determines the design of the software.

From there, that design is the guiding principle for how people build the system. It applies on all levels, from code to architecture. Any conscious decision in software development becomes an integral part of the design process. That means domain models, software modules, application programming interfaces and design patterns are just as important to software design as field declarations, if statements, hash tables and method declarations. All of these determine how stable the design is.

How Does Domain-Driven Design Work? 

Next, how do you start to add domain-driven design into this? Domain-driven design centers on programming a domain model that has a rich understanding of the processes and rules of a domain;for example, an e-commerce checkout feature. You should focus on the domain, which is a way of breaking the application into smaller areas according to its business rules.

Here are the building blocks of domain-driven design:

  • Entity: Entities are objects meant to be unique within the domain. Developers achieve these by using one or more proprieties to mark a given entity. It is crucial to identify information in a consistent manner to coordinate and control behavior to maintain security.
  • Value Objects: Unlike entities, value objects don’t have an identity. Only their properties distinguish between two instances. In domain-driven design, value objects are immutable and conceptually whole. They ensure centralized validation of the information, thus reducing security bugs in an application. 
  • Data Events: These objects can record discrete events related to model activity within the system. While all events within the system could be tracked, a domain event is only created for some event types that ensure data integrity. 
  • Aggregates: Domain-driven design aggregates are clusters of domain objects that can be treated as a single unit. An example may be an order and its line items. These will be separate objects, but it’s useful to treat the order together with its line items as a single aggregate. They protect the modification of information in true invariants in a trusted boundary.
  • Repositories: These are authorization services. They use a global interface to provide access to all entities and value objects within a particular aggregate collection. 

Key Design Principles

  • Immutability: Problems involving data integrity and availability could lead to an adverse effect on the overall business. While designing value objects, you need to decide whether they should be mutable or immutable. This will keep the data consistent during its entire lifecycle and ensures that data can be obtained at the expected level of performance in a system.
  • Failing fast: You can cut down on security problems involving illegal input with software design practices like preconditions and design by contract. A contract specifies the preconditions required for the method to work as intended. It specifies the postconditions for how the object will change after the method is completed. Design by contract avoids situations that give rise to vulnerabilities. Secure handling involves ending the job as soon as it becomes clear that the preconditions aren’t met.
  • Validation: One major security problem can arise when you’re not validating user input. Make sure validation is in place both in the client and server side and while data is moving from the database. The following list shows a good order in which to do this. The order is from the quickest filters, cheapest in performance terms, to the more involved check.

Types of validation:  

  • Origin: Is the data from a trustworthy sender?
  • Size: Is it within the expected limit?
  • Lexical content: Does it contain the right characters and encoding?
  • Syntax: Is it in the right format?
  • Semantics: Does the data make sense?

Advantages of the Domain-Driven Design Approach

With domain-driven design as part of your software development, security can become a natural part of the process. It’s not tacked on at the end. Instead, it gets to the heart of the matter. Software design is central to the interest and competence of most developers, which makes secure-by-design concepts easy to adapt. By focusing on design, business and security concerns gain equal priority in the view of both business experts and developers. By choosing good design constructs, non-security experts are able to write secure code. And by focusing on the domain, many security bugs are solved implicitly. In this way, domain-driven design solves several problems at once. 

More from Mobile Security

Juice jacking: Is it a real issue or media hype?

4 min read - You get off a flight and realize your phone is almost out of battery, which will make getting an Uber at your destination a bit challenging. Then you see it — a public charging station at the next gate like a pot of gold at the end of the rainbow. As you run rom-com style to the USB port, you may briefly wonder if it’s actually safe from a cybersecurity perspective to plug in your phone. The answer is technically…

Third-party app stores could be a red flag for iOS security

4 min read - Even Apple can’t escape change forever. The famously restrictive company will allow third-party app stores for iOS devices, along with allowing users to “sideload” software directly. Spurring the move is the European Union’s (EU) Digital Markets Act (DMA), which looks to ensure open markets by reducing the ability of digital “gatekeepers” to restrict content on devices. While this is good news for app creators and end-users, there is a potential red flag: security. Here’s what the compliance-driven change means for…

A view into Web(View) attacks in Android

9 min read - James Kilner contributed to the technical editing of this blog. Nethanella Messer, Segev Fogel, Or Ben Nun and Liran Tiebloom contributed to the blog. Although in the PC realm it is common to see financial malware used in web attacks to commit fraud, in Android-based financial malware this is a new trend. Traditionally, financial malware in Android uses overlay techniques to steal victims’ credentials. In 2022, IBM Security Trusteer researchers discovered a new trend in financial mobile malware that targets…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today