5 Domain primitives

 

This chapter covers

    • How domain primitives create secure code
    • Mitigating data leaks with read-once objects
    • Improving entities with domain primitives
    • Ideas from taint analysis

    In chapter 4, you learned about powerful design constructs like immutability, failing fast, and validation. Those constructs do indeed address several security issues, such as invalid input, illegal state, and data integrity, but applying them individually isn’t an effective way of achieving secure code. Table 5.1 shows the problem areas we’ll address in this chapter and those constructs that will help you achieve a greater level of security.

    Table 5.1 Problem areas addressed (view table figure)
    Section Problem area
    Domain primitives and invariants Security issues caused by inexact, error-prone, and ambiguous code
    Read-once objects Security problems due to leakage of sensitive data
    Standing on the shoulders of domain primitives Security issues caused by code burdened by too much complexity

    5.1 Domain primitives and invariants

    5.1.1 Domain primitives as the smallest building blocks

    5.1.2 Context boundaries define meaning

    5.1.3 Building your domain primitive library

    5.1.4 Hardening APIs with your domain primitive library

    5.1.5 Avoid exposing your domain publicly

    5.2 Read-once objects

    5.2.1 Detecting unintentional use

    5.2.2 Avoiding leaks caused by evolving code

    5.3 Standing on the shoulders of domain primitives

    5.3.1 The risk with overcluttered entity methods

    5.3.2 Decluttering entities

    5.3.3 When to use domain primitives in entities

    5.4 Taint analysis

    Summary

    sitemap