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