Skip to content

Definitions in Software

Security Experience

General

Security experience for a software developer means the practical ability to design, build, and maintain software that resists cyber-attacks and protects sensitive user data.

Key Areas of Security Experience

  • Secure Coding: Writing clean code that avoids common flaws. Developers often use guidelines from the OWASP Foundation to stop attacks like SQL injection (where hackers steal database data).
  • Authentication and Authorization: Building safe login systems. This includes setting up multi-factor authentication (MFA) and ensuring users only see data they are allowed to see.
  • Data Encryption: Protecting private information. This means scrambling data while it moves across the internet or sits on a server so strangers cannot read it.
  • Vulnerability Testing: Finding and fixing security holes. Developers use automated tools to scan code for bugs before the software is released to the public. (Penetration testing)
  • Dependency Management: Checking third-party code and libraries for known safety issues before adding them to a project.

Domain-Driven Design (DDD)

General

It is a software development approach that focuses on matching the structure and language of your code to the real-world business problem you are trying to solve.

Coined by Eric Evans in 2003, DDD is not a specific technology or framework. Instead, it is a set of philosophy and modeling practices designed to handle deeply complex business logic by bridging the gap between technical developers and business experts.

Here is a breakdown of the core concepts, split into how you think about the business (strategic) and how you build the code (tactical).

Strategic Design (The Big Picture)

Before writing code, DDD forces you to map out the business landscape.

  • The Domain: The overall business problem you are trying to solve (e.g., "E-commerce").
  • Subdomains: Breaking the domain into manageable pieces.
    • Core Domain: The unique value of the business (e.g., the recommendation engine).
    • Supporting Domain: Necessary but not unique (e.g., inventory tracking).
    • Generic Domain: Standard problems with off-the-shelf solutions (e.g., payment processing).
  • Bounded Context: Clear boundaries around different parts of the system. Within one boundary, a word means exactly one thing. For example, a "Product" means something completely different to the Inventory team (dimensions, weight) than it does to the Sales team (price, discounts).
    DDD separates these into different code modules or microservices.
  • Ubiquitous Language: Shared, common vocabulary used by both developers and business stakeholders.
    If the business calls a user a "Subscriber," the code must use the class name Subscriber, not User or Account.

Tactical Design (The Code Blueprint)

Once the boundaries are set, DDD provides specific patterns to structure your software logic inside a Bounded Context.

  • Entities: Objects that have a unique, thread-safe identity that persists over time. A Customer is an entity; even if they change their name or address, they are still the same customer.
  • Value Objects: Objects defined entirely by their attributes, with no distinct identity. They are immutable. For example, an Address or a Money object (50 USD). If you change the street name, it is simply a new Address object.
  • Aggregates: A cluster of associated Entities and Value Objects is treated as a single unit for data changes. Every Aggregate has a single Aggregate Root (the gatekeeper). To change something inside the cluster, you must go through the Root to ensure business rules aren't broken.
  • Repositories: An abstraction layer used by the domain layer to save and retrieve Aggregates from database storage, keeping data persistence logic completely separate from business logic.
  • Domain Events: A record of something significant that happened in the business domain (e.g., OrderPlaced, InvoiceSent). Other parts of the system can listen for these events and react.

Direct Comparison: Traditional vs. Domain-Driven

Many standard applications are built using a Data-Driven (CRUD) approach, which focuses on database tables first. DDD flips this focus completely.

Feature Traditional / CRUD Approach Domain-Driven Design (DDD)
Starting Point Designing database tables and relationships. Modeling real-world business behavior and rules.
Focus How data is stored and retrieved. What the business does and what rules apply.
Language Technical terms (Tables, Rows, Foreign Keys). Business terms (Ubiquitous Language).
Best Used For Simple apps, reporting tools, basic data entry. Highly complex systems with intricate business rules.