1. Fashion, Gist, and Modernity

You can use Fashion, Gist, and Modernity to separate what your software looks like, what the business needs it to mean and do, and what technology runs it—especially when you model the business Gist in MDriven Designer.

Software contains different kinds of decisions. They change for different reasons and at different speeds. Treating them as one problem makes a change in technology or user-interface style look like a reason to rebuild business knowledge.

MDriven distinguishes three areas:

| Area | What it describes | What commonly drives change | Example in an order system | |---|---|---|---| | **Fashion** | The finish: user interface (UI) and user experience (UX). | Design trends and user expectations. | How an order form is laid out, styled, and presented to the user. | | **Gist** | The business information, its relationships, and the business rules that govern it. | Internal and external business-process changes. | An `Order` has `OrderLines`; an order cannot be completed without a customer and at least one line. | | **Modernity** | The infrastructure and technical approach needed to run the system. | Technology, platforms, architecture, and operational requirements. | Storing information in a relational database, network transport, backup, servers, and programming-language or application-stack choices. |

1. 1. Why the separation matters

Fashion, Gist, and Modernity have different lifecycles.

- **Fashion** changes when expectations of look and feel change. - **Modernity** changes when the technology landscape changes, for example when an organization changes its delivery approach or technical stack. - **Gist** changes as the business learns, changes its processes, or introduces new rules.

A change in one area should not force unnecessary change in the others. For example, changing the order form from a dense desktop-oriented layout to a browser-oriented layout is a Fashion change. It should not require you to rediscover that an order needs lines, that each line refers to a product, or which rules permit an order to proceed.

The same applies to infrastructure. Changing how information is persisted or delivered is a Modernity change. The business meaning of `Order`, `Customer`, and `Product` remains Gist unless the business itself changes those meanings.

> **Principle:** Do not hard-fix together things that change at different intervals and for different reasons.

A house, its wallpaper, and its lightbulbs illustrate the distinction. A lightbulb is replaced more often than the house is rebuilt, and wallpaper can change without changing the building structure. In software, Fashion and Modernity often change faster than the Gist.

1. 1. Identify the three areas in a feature

When you discuss a requirement, classify each decision before implementing it.

Consider this requirement: **“Users must place orders and see whether an order can be completed.”**

| Question | Classification | Example decision | |---|---|---| | What business concepts exist, and how do they relate? | Gist | Model `Order`, `OrderLine`, `Customer`, and `Product`. | | What rules govern those concepts? | Gist | An order requires a customer and one or more order lines before completion. | | How should the user see and interact with the order? | Fashion | Show order lines in a grid, use a compact or spacious layout, and choose labels and visual emphasis. | | How is the information stored, transported, secured, backed up, and run? | Modernity | Use the selected database and runtime infrastructure to persist and serve the order information. |

This classification prevents a technical preference from becoming a business rule, or a UI preference from defining the business model.

For example, “show a red button” is Fashion. “Do not permit completion until the order has lines” is Gist. “Persist the order information when the system is not running” is Modernity.

1. 1. Keep the Gist explicit in the model

The Gist is the structured knowledge that makes the system specific to the business it supports. It includes:

- the information the business handles; - the names and relationships of that information; - the rules that control how the information can change.

In MDriven, keep this knowledge in a machine-readable model in **MDriven Designer**. The model can be understood, discussed, criticized, and evolved before it takes the form of implementation-specific code.

Use domain terms in the model. A model with `Order`, `Customer`, and `OrderLine` communicates the business meaning more clearly than abstract technical names. This shared terminology supports a common language among developers, modelers, domain experts, and stakeholders.

For example, a stakeholder can discuss the rule “an order must have at least one order line” directly with the people who maintain the model. The discussion is about the business rule, not about database tables or UI controls.

See Model-Driven Architecture for the relationship between modeling and Domain-Driven Design (DDD), including the goal of a ubiquitous language.

1. 1. Let Fashion and Modernity change independently

A model executor turns a system Gist into a running system in a particular environment. The executor addresses the Modernity required by that environment; the presentation supplies the Fashion.

This means you should aim to preserve the Gist while allowing Fashion and Modernity to evolve independently:

1. **Model the business Gist** using the business concepts, relationships, and rules. 2. **Use the current technical approach** to execute and operate that model. 3. **Apply the current UI and UX design** without embedding its transient choices in the business model. 4. **Revisit the Gist when the business changes**, not because a UI trend or infrastructure choice changed.

The goal is not to ignore Fashion or Modernity. Both matter. A system needs an appropriate user experience and suitable infrastructure to be usable, maintainable, secure, and operational. The goal is to avoid confusing either of them with the business problem.

1. 1. What this protects

When Gist is mixed into implementation-specific technology and presentation code, a technology shift can trigger a broad rewrite. During that rewrite, teams may need to ask the business to restate requirements and can lose detailed knowledge accumulated in the existing system.

Keeping the Gist separate protects the business knowledge from technology change. It also makes the Gist an actively maintained description of what information the business handles and how that information behaves.

That description is an organizational asset. It lets people discuss future changes with more precision because the current concepts and rules are explicit rather than scattered across technical implementations.

For a deeper discussion of models as the home of the system Gist and model executors as the changing technical environment, see Training:Luckily UML is Not Forbidden. For the consequences of mixing Gist and Modernity, see Training:What is not to like.

1. 1. Apply the distinction during design discussions

Use these questions when reviewing a requirement or proposed change:

1. **Is this a business concept, relationship, or rule?**

  If yes, it belongs to the Gist. Model it using the language of the domain.

2. **Is this about appearance or interaction?**

  If yes, it belongs to Fashion. Treat it as a UI or UX decision.

3. **Is this about storage, transport, runtime, architecture, or a technical platform?**

  If yes, it belongs to Modernity.

4. **Does the proposed implementation tie one category to another unnecessarily?**

  For example, do not make a business rule depend on a particular screen layout, and do not treat a database choice as the definition of a business concept.

5. **What caused the change?**

  A new business process should change the Gist. A new visual direction should change Fashion. A platform or operational change should change Modernity.

1. 1. Related reading

- Training:Luckily UML is Not Forbidden — why a machine-readable model can preserve the system Gist across changing execution environments. - Model-Driven Architecture — Domain-Driven Design and the shared language of the model. - Training:Praise to UML — further examples of Fashion, Gist, and Modernity outside software. - Training:What is not to like — why mixing different lifecycles leads to costly rewrites. - Business Differentiation and Value — why the pattern, or Gist, is the durable business asset. - Training:What is next — the next chapter in the MDriven training material.