Deriving domain-driven design

If you thought about it for long enough, you would invent domain-driven design. This is a talk I gave at DevLab ‘21 about deriving domain-driven design from first principles to demonstrate that it’s an intrinsic property of well architected systems.

Strengthen your types

“Static typing” and “strong typing” are frequently conflated, as for many people a statically typed language implies that programs written with it must also be strongly typed. That’s notionally true as the variables themselves have types, not just the values, but I’d argue that most statically typed programs are actually fairly weakly typed.

Feature flags

Introducing feature flags helps to separate release from deployment, and allow changes to be partially rolled out on a percentage basis and/or to target groups of users. It cannot completely separate these two things as some changes such as database migrations are all or nothing. However, it can significantly reduce the risk of deployments.

Modelling composite types

A composite type is one that can have different possible types of value, for example contact info might be either a phone number or an email address. Other common names for this—depending on programming language and context—are sum types, tagged unions, disjoint unions, discriminated unions, coproducts, or variant types (not the same as the old COM concept).

The engineering career triangle

Engineering career progression is often described as a ‘ladder’ or ‘track’, where you can also switch into a parallel management track. However, this doesn’t adequately illustrate where the tech lead role sits, or why the staff+ engineer levels have at least as much in common with management as they do with coding. To be able to explain this we need to separate the concepts of management and leadership. The result is the engineering career triangle.


© 2013-2021 Greg Beech. All rights reserved.

Powered by Hydejack v9.0.5