# Best practices for modeling systems that evolve over time — mutability, patterns, and performance?

**URL:** <https://discourse.julialang.org/t/best-practices-for-modeling-systems-that-evolve-over-time-mutability-patterns-and-performance/128626>\
**Category:** Modelling & Simulations\
**Tags:** question\
**Created:** [May 2, 2025, 12:49pm UTC](https://discourse.julialang.org/t/best-practices-for-modeling-systems-that-evolve-over-time-mutability-patterns-and-performance/128626 "2025-05-02T12:49:33Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![PatrickHaecker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/patrickhaecker/32/222891_2.png) [@PatrickHaecker](https://discourse.julialang.org/u/PatrickHaecker)\
**Post date:** [May 3, 2025, 4:29am UTC](https://discourse.julialang.org/t/best-practices-for-modeling-systems-that-evolve-over-time-mutability-patterns-and-performance/128626/3 "2025-05-03T04:29:46Z")

</div>

When it gets to modeling and you are in doubt you should follow @ChrisRackauckas advice. 😀

That being said, if you want to stick to your `struct`-based design or are interested in a general discussion, here are my thoughts about your example:

- Often the “outer” structs need to be mutable for good performance, while the smaller “inner” structs can be immutable. In your case you probably could make `CelestrialBody` immutable and work with `Ref` if managing the updates is too complicated otherwise. The question is, whether it’s worth it in this case, because `CelestrialBody` seems to have [object identity](https://discourse.julialang.org/t/why-const-fields-in-a-mutable-struct-instead-of-mutable-field-in-ordinary-struct/103454/9), so modeling it as a mutable struct seems to be the right thing.
- Try to avoid abstract types in a struct definition. Your alternatives are
  - Concrete types (obviously)
  - Parameterized types
  - Union(All) types

- Starting all field names with an underscore is not a typical Julia style. If you want to make sure that they are not accessed outside the module, a private-symbol check in `Aqua.jl` will probably be more robust (not implemented yet, however)
- `AbstractPoint` might be misleading, as I would have assumed, that an `AbstractPoint` always has a position, which your objects do not seem to have. Maybe you find a better name (depending on your specific needs, maybe `AbstractPointObject`)

---

_[View the full topic](https://discourse.julialang.org/t/best-practices-for-modeling-systems-that-evolve-over-time-mutability-patterns-and-performance/128626)._