Design note: records are anemic by design
This note goes with Records in EK9. An EK9 record has public fields that you can change, a few constructors and operators, and no methods. Some will call that an anemic model. It is, on purpose.
Data carries no behaviour
When you transmit a data structure, or store it in a database or a file, no 'behaviour' goes with it. A record says so: it is the data, with only the limited, controlled behaviour its constructors and operators give it. If you need more than that, use a class.
In EK9 it is not poor style to pass a 'Data Transfer Object' around and work on its public data with functions. That is what it is for.
Mutation without immutable types
Changing the state inside a record can look dangerous: mutation of aggregate data should be controlled. That is why many languages have immutable data structures.
EK9 has no immutable, final or const modifier (it does have constants). It controls mutation another way, with the pure modifier: a method or function marked pure cannot mutate the data passed to it. That is what lets any data structure stay un-mutated. It also leads you to Streams/Pipelines, and to copying data and then altering the copy as you process it.
"It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures." - Alan Perlis (SICP Foreword).
You may not agree with this, but it is a valid approach to software development. If you prefer full data encapsulation and a rich object model, use classes and components, and leave out records.