papers.adligo.com

MMM (Matrix Memory Modeling) [aka 3M]

Author: Scott Morgan
Created: 2026-01-04
Edited: 2026-01-04
Id: 1.3.6.1.4.1.33097.3.95
Copywrite 2020-2026 Adligo Inc

Summary

Matrix Memory (RAM) Modeling is a system for modeling the problem domain of software systems. They are always Passive Models#1.3.6.1.4.1.33097.3.32. Unlike the Domain Driven Design#1.3.6.1.4.1.33097.3.20.0 approach, they are derived via a system of modeling rules.

The intent of Matrix Memory Modeling (aka MMM or 3M) is simply to build models that we NOT need to be refactored in the future. This saves on time and effort during the duration of large complex projects which may need to be maintained for years, decades, or centuries.

This system splits the difference to some degree between the Graph Theory#1.3.6.1.4.1.33097.1.0.12 and Relational Model#1.3.6.1.4.1.33097.5.0 divide. It attempts to combine the best of both worlds, while still allowing for the flexibility of both.

Step 1) Identify and Create all Enums

Step 2) Create a relational model of the data

Take a look at Codd’s relational model and start there. Even if you are NOT planning on using a relational database, you should still be able to derive a relational model. The level of normal form is not super important, however, you will likely want to shoot for 3NF#1.3.6.1.4.1.33097.5.0.0.3 or higher. Relational Normal Forms#1.3.6.1.4.1.33097.5.0

Step 3) Mutants

Create a mutable model for each entity (aka row in the relation model) and add the word Mutant to the name.

For Example, Consider the following;

• PersonMutant represents a human.
• OrganizationMutant represents a company, non-profit, club, or government agency.
• PersonToOrgTypeMutant represents the type of relationship between a person and an organization (i.e., Employee, Employer, Volunteer, etc.).

Step 4) Extract Interfaces [Optional]

Extract the interfaces into a diamond pattern as follows;

• I_XyzConstants The shared constants for this entity.
• I_XyzMutators The mutators (setters) for this entity.
• I_Xyz The immutable interface (getters, accessors) for this entity.
• I_XyzMutant The mutable interface (getters (or accessors) and setters) for this entity.

For Example;

    I_PersonConstants
     /              \
    /                \
   /                  \
I_Person          I_PersonMutators
   \                  /
    \                /
     \              /
      I_PersonMutant   

Step 5) Share and Aggregate as Necessary [Optional]

Use the Sharable Aggregation pattern to compose or combine entities where appropriate. For Example;

• PersonRelationsMutant A single human, and its relationships to other people and organizations.

Step 6) Create Validators [Optional]

After slightly less than a decade of experience (A posteriori) has identified that validators (form validation / in memory rules) are easiest to create and maintain separate from the other problem domain models. For example;

• PersonValidator should;

implement the I_PersonMutators interface, collect traceable validation issues (if any) and provide a valid I_Person when the rules pass.

Step 7) Extract Shared Aggregate Interfaces [Optional]

Extract the shared aggregate interfaces as necessary following the pattern from Step 4.

    I_PersonRelationsConstants
     /                        \
    /                          \
   /                            \
I_PersonRelations          I_PersonRelationsMutators
   \                            /
    \                          /
     \                        /
      I_PersonRelationsMutant   

Step 8) Iterate on the Model [Optional]

Over time, you may discover that you need to add more entities or change the way you model the problem domain.

Citations

https://en.wikipedia.org/wiki/A_priori_and_a_posteriori

Modeling#1.3.6.1.4.1.33097.3.20

Domain Driven Design#1.3.6.1.4.1.33097.3.20.0