Traditional State

Traditional State is a classic approach to data persistence where an application stores only the current state of objects in the database. Changes overwrite previous values, and historical events are not tracked, which makes this model simple and quick to implement.

✅ When is it appropriate

Traditional State is suitable if most of the following apply:

low to medium domain complexity
no need for audit trails, detailed change history, or the ability to reconstruct past data states
a small team or limited experience with complex architecture
low frequency of changes in business rules
auditing or historical data tracking is not required

Traditional State fits well here because storing only the current value of each record is exactly what relational databases are optimised for. There is no additional overhead for recording events or replaying history, so reads and writes are straightforward and the data model stays easy to understand.

❌ When is it NOT appropriate

Traditional State may not be ideal if:

high domain complexity with multiple subdomains
a full audit trail is required, meaning every change to data must be recorded with who made it and when
need for rollbacks, historical data, or auditing
frequent changes in business rules
the system must be able to reconstruct any past state of data at any point in time

When an audit trail or historical reconstruction is required, Traditional State falls short because previous values are permanently overwritten on every update. There is no built-in record of what the data looked like before, so reproducing past states requires adding a separate, often complex logging mechanism on top.

👍 Advantages

simple to implement and understand
low complexity for smaller projects
fast development and deployment
direct mapping of data objects to database rows
suitable for MVPs and prototypes

👎 Disadvantages

reads and writes share the same data model
more complex auditing and change tracking
limited flexibility for complex domains
retrofitting event-driven integration is difficult because no event history is stored
rollbacks and historical data are difficult

🛠️ Typical use cases

small to medium applications with simple entities
MVPs and prototypes
internal systems and admin panels
projects with low change frequency and low complexity
traditional web applications and APIs

⚠️ Common mistakes (anti-patterns)

implementing Traditional State for highly complex domains
ignoring the need for auditing and historical data
trying to reconstruct a past business state or replay a sequence of changes
poor documentation and testing of operations

Using Traditional State for domains with strict auditing requirements forces you to bolt on a logging layer later, which is costly and error-prone. Trying to replay history that was never recorded leads to data loss or incorrect results. Poor documentation makes it hard to understand which operations modify state and why, causing bugs that are difficult to trace.

💡 How to build on it wisely

Recommended approach:

Use Traditional State for small and medium projects.
Monitor the growth of the domain and the team.
As the project grows, consider Event Sourcing or CQRS.
Document operations and validations.
Monitor and test both read and write operations.

Traditional State is the right default for most applications where the current value of data is all that matters. The key signal to reconsider is when stakeholders start asking questions like "what did this record look like last week?" or "who changed this and when?", if that happens regularly, it is time to evaluate Event Sourcing or adding a dedicated audit log before the data model becomes too hard to change.

Feedback & Sharing

Give us your thoughts on this page, or share it with others who may find it useful.

Share with your network:

Feedback

Found this helpful? Let me know what you think or suggest improvements 👉 Contact me.