LCN Wafer Inspection

Appearance

PART 1 — WHAT “DOMAIN MODEL” MEANS IN MACHINE SOFTWARE ​

In machine software, the domain model is the software’s mental representation of the real machine.

It is the answer to questions like:

  • What things exist in this machine?
  • What do those things mean?
  • What state do they have?
  • What behavior belongs to them?
  • How do they relate to each other?

A good domain model lets engineers look at the codebase and say:

“Yes, this software thinks about the machine the same way the real machine works.”

That is the real goal.

In industrial systems, this matters more than in many business systems because the software is not just managing records. It is representing:

  • physical components
  • physical constraints
  • operating modes
  • long-running machine activities
  • state that evolves over time
  • interactions between software and hardware reality

So when we say domain modeling for machine systems, we mean designing software concepts that reflect the machine in a way that is accurate, stable, and understandable over time.

This sits naturally inside industrial software architecture, where clear domain boundaries are one of the core concerns for maintainability in hardware-heavy systems.

Domain model vs database model vs UI model ​

These are often confused, and that confusion causes a lot of damage.

Domain model ​

The domain model represents the machine reality and machine meaning.

Examples:

  • Machine
  • Axis
  • Station
  • InspectionJob
  • Recipe
  • SubsystemState
  • SafetyCondition

These concepts exist because the machine exists.

Database model ​

The database model represents how information is stored.

Examples:

  • MachineRecipeRecord
  • RunHistoryRow
  • AlarmLogEntry
  • DeviceConfigTable

These concepts exist because persistence exists.

UI model ​

The UI model represents what the screen needs to display or edit.

Examples:

  • AxisStatusViewModel
  • RecipeEditorRow
  • AlarmPanelItem
  • ManualControlScreenState

These concepts exist because operators and service engineers need an interface.

A strong system keeps these separate.

If your domain model becomes a copy of database tables, the software becomes storage-driven. If your domain model becomes a copy of screens, the software becomes UI-driven. In machine systems, both lead to confusion because the software stops reflecting the actual machine.

Why a good domain model makes the system understandable ​

A good domain model gives you:

  • a stable vocabulary
  • clear ownership of behavior
  • less duplication
  • cleaner boundaries across layers
  • easier debugging
  • easier onboarding of engineers
  • safer evolution as the machine grows

In real machine projects, the codebase often becomes hard not because the algorithms are impossible, but because the concepts are blurry.

You start seeing things like:

  • three different meanings of “state”
  • device names leaking everywhere
  • workflow code directly manipulating low-level objects
  • configuration scattered across UI, services, and adapters
  • no clear place to put machine rules

That is usually not just a coding problem. It is a modeling problem.

PART 2 — CORE DOMAIN CONCEPTS IN MACHINE SYSTEMS ​

Most industrial machines can be understood through a set of core concepts. The exact names vary, but the structure is surprisingly consistent.

Typical core concepts ​

1. Machine ​

The top-level software concept representing the whole equipment.

It is not just a container of devices. It represents the machine as an operational system.

It usually has:

  • identity
  • current mode
  • current machine-level state
  • subsystems
  • active recipe or setup
  • current run context

2. Subsystem ​

A meaningful functional part of the machine.

Examples:

  • motion subsystem
  • vision subsystem
  • IO subsystem
  • vacuum subsystem
  • material handling subsystem
  • illumination subsystem

A subsystem is useful when the machine is too large to reason about as one flat object model.

3. Device ​

A concrete controllable or observable hardware element.

Examples:

  • camera
  • motor controller
  • laser
  • light controller
  • PLC link
  • sensor module
  • vacuum controller

A device is closer to hardware reality than a subsystem.

4. Axis ​

A software representation of controllable movement along one degree of freedom.

Examples:

  • X axis
  • Y axis
  • Z axis
  • Theta axis
  • focus axis

An axis is often more useful than modeling raw motors directly, because machine software reasons in terms of movement capability and position, not just electrical hardware.

5. Position / Coordinate ​

A domain concept representing where something is in a meaningful reference frame.

Examples:

  • stage position
  • load position
  • inspection origin
  • camera-relative coordinate
  • recipe-defined target position

This is not just a tuple of numbers. It often includes semantic meaning and frame awareness.

6. Workflow / Operation ​

A meaningful machine activity.

Examples:

  • home machine
  • load wafer
  • align part
  • inspect panel
  • unload tray
  • calibrate camera

This represents what the machine is doing as an operation, not just what individual devices are doing.

7. State ​

State is unavoidable in machine systems.

Examples:

  • machine state
  • subsystem state
  • axis state
  • workflow state
  • material presence state
  • readiness state

But state must be modeled carefully. “State” is one of the most overloaded words in machine software.

8. Recipe / Configuration ​

A domain concept representing the parameters that define how the machine should operate for a given product, process, or scenario.

Examples:

  • motion targets
  • exposure settings
  • alignment tolerances
  • inspection thresholds
  • timing values
  • enabled stations

A recipe is not just configuration data. It is part of how the machine behaves in production.

Example domain diagram ​

text
+--------------------------------------------------+
|                    Machine                       |
|--------------------------------------------------|
| Id                                               |
| Mode                                             |
| MachineState                                     |
| ActiveRecipe                                     |
+--------------------------------------------------+
          | owns
          v
+-------------------+     +-------------------+     +-------------------+
| MotionSubsystem   |     | VisionSubsystem   |     | IOSubsystem       |
+-------------------+     +-------------------+     +-------------------+
| Axes              |     | Cameras           |     | Sensors           |
| MotionState       |     | VisionState       |     | Actuators         |
+-------------------+     +-------------------+     +-------------------+
        |                        |                          |
        v                        v                          v
+---------------+        +---------------+          +---------------+
| Axis          |        | Camera        |          | Sensor        |
+---------------+        +---------------+          +---------------+
| Name          |        | Name          |          | Name          |
| Position      |        | Status        |          | SignalState   |
| AxisState     |        | Exposure      |          | Value         |
| Limits        |        | TriggerMode   |          |               |
+---------------+        +---------------+          +---------------+

+--------------------------------------------------+
|                  Workflow / Operation            |
+--------------------------------------------------+
| HomeMachine                                      |
| LoadPart                                         |
| AlignPart                                        |
| InspectPart                                      |
| UnloadPart                                       |
+--------------------------------------------------+

+--------------------------------------------------+
|                    Recipe                        |
+--------------------------------------------------+
| MotionParameters                                 |
| VisionParameters                                 |
| ProcessParameters                                |
+--------------------------------------------------+

How these relate ​

The important point is not just the nouns. It is the relationship shape:

  • Machine is the operational whole
  • Subsystem groups a functional part
  • Device represents concrete hardware capability
  • Axis represents motion semantics
  • Workflow represents machine activities
  • Recipe influences behavior
  • State exists at multiple levels and must have clear ownership

That shape matters because it mirrors how real machines are understood by experienced engineers.

PART 3 — MAPPING PHYSICAL REALITY TO SOFTWARE ​

This is where machine domain modeling becomes real.

The physical machine contains motors, encoders, cameras, sensors, fixtures, stations, conveyors, wafers, trays, doors, vacuum lines, and many other things.

But software should not blindly mirror hardware structure.

It should model behaviorally meaningful abstractions.

Physical system to software abstraction ​

Motor → Axis ​

In many systems, the software should not expose “Motor #3” as the main business concept.

Why?

Because machine logic usually cares about:

  • where the stage is
  • whether movement is complete
  • whether homing was done
  • whether travel is safe
  • what coordinate frame applies

That is an Axis concept, not a raw motor concept.

So instead of this:

text
MotorController.Channel3.SetSpeed(...)
MotorController.Channel3.Move(...)

the domain model should usually think like this:

text
StageXAxis.MoveTo(InspectionOrigin.X)

The hardware still exists. But the software concept matches machine meaning better.

Camera → Device abstraction ​

A camera is a real device, but the domain usually should not care about every SDK detail.

The domain meaning is more like:

  • inspection camera
  • alignment camera
  • review camera

Those are machine roles.

So the model should prefer role-driven naming over vendor-driven naming.

Bad:

text
BaslerCamera1
BaslerCamera2

Better:

text
AlignmentCamera
InspectionCamera
ReviewCamera

Because the role is stable even if the vendor changes.

Process → Workflow ​

The real machine does not just “call some functions.” It performs operational sequences such as:

  • initialize
  • home
  • load
  • align
  • inspect
  • unload
  • recover

These are domain concepts. They should exist explicitly.

Sensor → signal / condition / state ​

A sensor is physical hardware, but the domain meaning may not be “sensor” at all.

A vacuum sensor may be modeled in software as:

  • VacuumPresent
  • ChuckVacuumState
  • IsPartClamped

because that is the meaningful concept to the machine behavior.

This is an important rule:

Model what the machine cares about, not only what the hardware is called ​

That is one of the most important modeling instincts in this domain.

Abstraction must match behavior, not just structure ​

Many bad models are structurally correct but behaviorally useless.

Example:

A machine has four motors, two cameras, six sensors.

A weak model simply mirrors the parts list:

text
Motor
Motor
Motor
Motor
Camera
Camera
Sensor
Sensor
...

That may be hardware-accurate, but it is too low-level for the machine software to reason about clearly.

A better model reflects the operational meaning:

text
WaferStage
FocusAxis
LoadPort
InspectionHead
AlignmentCamera
ReviewCamera
ChuckVacuum
DoorInterlock

This model is more useful because it matches the real machine’s behavior and operator vocabulary.

Layered mapping view ​

text
+------------------------------------------------------+
| Application / Workflow Layer                         |
|------------------------------------------------------|
| LoadWafer | AlignWafer | InspectWafer | UnloadWafer |
+------------------------------------------------------+
                      |
                      v
+------------------------------------------------------+
| Domain Model Layer                                   |
|------------------------------------------------------|
| Machine | Stage | Axis | CameraRole | Recipe | State |
+------------------------------------------------------+
                      |
                      v
+------------------------------------------------------+
| Device / Integration Layer                           |
|------------------------------------------------------|
| MotionController | CameraSdk | PLCAdapter | IOCard  |
+------------------------------------------------------+
                      |
                      v
+------------------------------------------------------+
| Physical Machine                                     |
|------------------------------------------------------|
| Motors | Encoders | Cameras | Sensors | Actuators   |
+------------------------------------------------------+

This is the clean picture.

The application layer coordinates work. The domain layer names and structures machine meaning. The device layer talks to real hardware.

When these are blurred, the system becomes fragile.

PART 4 — MODELING BEHAVIOR VS DATA ​

A common mistake is building a machine domain model as a pile of DTO-like classes.

That gives you a software model that stores information, but does not express machine rules.

Anemic model ​

text
class Axis
{
    string Name;
    double Position;
    bool IsHomed;
    double MinLimit;
    double MaxLimit;
}

This is just data.

Then the logic ends up scattered elsewhere:

  • UI checks limits
  • service checks homed status
  • workflow checks readiness
  • device adapter checks safety
  • utility class computes coordinate validity

That is how machine systems become chaotic.

Richer model ​

A better domain object encapsulates machine meaning.

text
Axis
 - knows whether it is reference-valid
 - knows whether a target is within its allowed domain range
 - knows whether movement is conceptually allowed
 - exposes domain-relevant operations or invariants

Not every device wrapper should become a huge object, and not every class needs methods everywhere. But machine domain objects should not be passive bags of fields.

Domain objects should encapsulate behavior ​

In this domain, useful behavior may include:

  • validating semantic commands
  • protecting invariants
  • translating raw values into meaningful state
  • exposing domain concepts clearly
  • preventing illegal domain transitions

Examples:

  • Recipe.ValidateFor(MachineConfiguration)
  • AxisTarget.MustBeWithin(SoftLimitRange)
  • InspectionRegion.TransformToStageCoordinates(...)
  • MachineMode.Allows(OperationType.ManualJog)

These are domain behaviors.

Where logic should live ​

This is critical.

Device layer ​

Owns hardware communication behavior.

Examples:

  • sending command to controller
  • reading sensor register
  • managing SDK connection
  • handling transport timeout
  • converting vendor error codes

This is not domain modeling. This is integration.

Application layer ​

Owns orchestration and use-case coordination.

Examples:

  • start inspection run
  • execute load sequence
  • coordinate multiple domain objects
  • decide which operation to call next
  • manage transaction-like workflow progression

This is not pure domain either. This is orchestration.

Domain model ​

Owns machine meaning and machine rules.

Examples:

  • what a valid recipe means
  • what a safe target means conceptually
  • what state combinations are meaningful
  • what a subsystem is responsible for
  • what a workflow step logically requires

A good heuristic:

  • If the rule depends on machine meaning, it belongs near the domain.
  • If the rule depends on hardware protocol details, it belongs near the device layer.
  • If the rule is about multi-step coordination, it belongs in the application layer.

PART 5 — AGGREGATES & BOUNDARIES ​

In machine systems, aggregates are less about textbook DDD vocabulary and more about clear ownership boundaries.

You need to know:

  • what belongs together
  • what changes together
  • what should be reasoned about as one unit
  • what should not be able to mutate from anywhere

Why boundaries matter ​

Without boundaries, everything can touch everything:

  • UI changes recipe fields directly
  • workflow changes axis flags directly
  • device callbacks mutate machine state directly
  • alarm handler updates subsystem status directly
  • helper classes recalculate state in five places

That creates coupling and eventually mistrust in the code.

Example aggregate shapes ​

Machine aggregate ​

Useful when there are machine-wide concepts that must remain consistent.

Examples:

  • operating mode
  • active product context
  • active recipe selection
  • machine-level readiness
  • major subsystem composition

Subsystem aggregate ​

Useful when a functional area has meaningful internal consistency.

Examples:

  • motion subsystem owns axes and motion readiness
  • vision subsystem owns cameras and acquisition configuration
  • handling subsystem owns grippers, vacuum, and part presence state

Device aggregate ​

Sometimes useful for a complex device with internal state and configuration.

Examples:

  • a vision station that includes camera + light + trigger setup
  • a robot module with controller + gripper + taught positions
  • a dispense head with pressure control + material state + purge status

Example relationship diagram ​

text
+----------------------------------------------------+
| MachineAggregate                                   |
+----------------------------------------------------+
| Mode                                               |
| MachineState                                       |
| ActiveRecipeId                                     |
+----------------------------------------------------+
| MotionSubsystem                                    |
| VisionSubsystem                                    |
| HandlingSubsystem                                  |
+----------------------------------------------------+

MotionSubsystem aggregate:
+----------------------------------------------------+
| MotionSubsystem                                    |
+----------------------------------------------------+
| MotionState                                        |
| ReferenceStatus                                    |
+----------------------------------------------------+
| XAxis                                              |
| YAxis                                              |
| ZAxis                                              |
| ThetaAxis                                          |
+----------------------------------------------------+

VisionSubsystem aggregate:
+----------------------------------------------------+
| VisionSubsystem                                    |
+----------------------------------------------------+
| VisionState                                        |
| ActiveOpticalSetup                                 |
+----------------------------------------------------+
| AlignmentCamera                                    |
| InspectionCamera                                   |
| LightController                                    |
+----------------------------------------------------+

Why clear boundaries reduce coupling ​

When ownership is clear:

  • state has one authoritative home
  • invariants are easier to enforce
  • engineers know where to put changes
  • UI and workflows depend on stable concepts
  • debugging is easier because responsibility is traceable

In industrial systems, this matters because state is already hard enough. Ambiguous ownership makes it much worse.

PART 6 — REAL-WORLD MODELING MISTAKES ​

Mistake 1: Modeling based on the UI instead of machine reality ​

What it looks like ​

Classes are shaped around screens:

  • ManualPageModel
  • AxisGridRow
  • RecipeTabState
  • StationPanelData

and these become the main business concepts.

Why it happens ​

UI is visible, immediate, and easy to discuss. So teams unconsciously let the screen structure become the system structure.

Impact ​

The model becomes unstable because screens change more often than machine meaning. You also end up duplicating the same concept differently across different views.

The machine should define the model. The screen should project it.

Mistake 2: Mixing domain logic with device logic ​

What it looks like ​

Workflow code or domain classes directly contain SDK calls, PLC register mapping, or raw hardware error handling.

Why it happens ​

Early prototypes are built quickly, and device APIs are the first things engineers touch.

Impact ​

You cannot reason clearly about machine behavior anymore. Vendor details leak everywhere. Testing becomes harder. Replacing hardware becomes painful.

Mistake 3: Duplicating concepts across layers ​

What it looks like ​

There are multiple versions of the same idea:

  • MachineState in UI
  • MachineStatus in workflow
  • MachineCondition in device manager
  • CurrentModeFlags in controller adapter

All overlapping, none authoritative.

Why it happens ​

Different teams solve local problems independently.

Impact ​

People stop trusting names. Bugs appear because layers disagree on reality.

This is especially common with:

  • readiness
  • state
  • alarm status
  • recipe activation
  • current position
  • part presence

Mistake 4: Unclear ownership of state ​

What it looks like ​

No one knows who truly owns:

  • axis position validity
  • whether machine is ready
  • whether recipe is active
  • whether subsystem is faulted
  • whether material is loaded

Why it happens ​

State is derived in many places and updated opportunistically.

Impact ​

Intermittent bugs, race conditions, stale UI, incorrect workflow branching, and endless debugging.

In machine systems, unclear state ownership is one of the fastest ways to produce fragile logic.

Mistake 5: Over-generalization too early ​

What it looks like ​

Teams create abstract base classes for every possible future machine:

  • IUniversalHardwareNode
  • IExecutablePhysicalUnit
  • BaseIndustrialComponent<TState, TCommand>
  • IProcessCapableEntity

Why it happens ​

Engineers want flexibility and elegance.

Impact ​

The model becomes harder to understand than the machine itself.

In industrial systems, overly generic naming often hides important real differences.

A wafer stage, a robot arm, and a light controller are not “just actuators” in any useful architectural sense.

Mistake 6: Modeling hardware inventory instead of operational meaning ​

What it looks like ​

The model mirrors cabinet contents or wiring diagrams instead of the machine’s functional structure.

Why it happens ​

Hardware documentation is often the easiest initial source.

Impact ​

Software becomes technically accurate but operationally awkward.

The operator thinks in terms of:

  • load
  • align
  • inspect
  • unload
  • recover

not in terms of controller slot numbers and cable mappings.

PART 7 — EVOLUTION OF DOMAIN MODEL ​

Machine systems change constantly.

Over time you get:

  • new device variants
  • new stations
  • new product recipes
  • new operating modes
  • new calibration steps
  • new diagnostics
  • new customer-specific behaviors

So the domain model must not only be correct today. It must be able to evolve without collapsing.

What makes a machine domain model evolvable ​

1. Good names ​

Names must reflect machine meaning, not temporary implementation details.

Prefer:

  • InspectionCamera
  • LoadPosition
  • ActiveRecipe
  • MachineMode

over:

  • Camera1
  • PosA
  • CurrentConfig
  • FlagSet

2. Stable abstractions ​

Base abstractions on what is likely to remain true even if hardware changes.

Example:

AlignmentCamera is more stable than BaslerAceCamera.

StageAxis is more stable than ServoChannel2.

3. Clear state ownership ​

As the system grows, unclear ownership becomes exponential pain.

4. Separation from infrastructure ​

The domain should survive hardware SDK changes, database changes, and UI redesigns.

5. Explicit concepts instead of informal conventions ​

If a concept matters, model it explicitly.

Examples:

  • MachineMode
  • RecipeRevision
  • ReferenceValidity
  • MaterialPresence
  • SafetyCondition

If you leave them implicit in booleans and comments, the model becomes harder to extend safely.

PART 8 — SOFTWARE DESIGN IMPLICATIONS ​

The domain model is not an isolated design artifact. It becomes the foundation of the whole system architecture.

Why domain model is foundational ​

It influences:

  • service boundaries
  • workflow design
  • UI vocabulary
  • persistence design
  • test structure
  • logging language
  • alarm wording
  • supportability

If the domain model is weak, the architecture will usually feel messy no matter how good the patterns look on paper.

Importance of clear naming ​

In industrial software, naming is not cosmetic. It is how teams agree on reality.

Strong naming reduces misunderstandings between:

  • software engineers
  • controls engineers
  • vision engineers
  • field service
  • operators

When names reflect the real machine, cross-functional communication gets much easier.

Importance of consistent concepts ​

A concept should mean one thing.

If “ready” means five different things in five layers, the system is already in trouble.

You want consistency around concepts like:

  • ready
  • homed
  • active recipe
  • loaded
  • aligned
  • safe
  • faulted
  • paused
  • recoverable

Separation from infrastructure ​

The domain should not be shaped by:

  • database schema
  • vendor SDK object model
  • UI layout
  • thread model
  • message transport

Those are implementation concerns. The domain should express machine meaning first.

Good vs bad approach ​

Bad ​

Ad hoc classes grow around immediate coding needs.

text
AxisInfo
AxisData
AxisStatusManager
MotionHelper
MachineRuntimeData
MainPageMachineState
RecipeServiceModel

No one knows which one is authoritative.

Good ​

An intentional model exists and other layers map to it.

text
Machine
MotionSubsystem
Axis
Position
Recipe
InspectionOperation
MachineMode
MachineState

Then:

  • UI maps from domain concepts
  • persistence maps from domain concepts
  • device adapters support domain concepts
  • workflows orchestrate domain concepts

That is the difference between a codebase that stays understandable and one that becomes tribal knowledge.

PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ​

How to explain domain modeling clearly ​

A strong explanation sounds like this:

In industrial machine software, the domain model is the software representation of the machine’s real operational world. It defines the core machine concepts, their relationships, their state, and the rules that belong to them. A good domain model is not shaped by database tables or UI screens. It is shaped by how the machine actually behaves physically and operationally.

How to explain mapping a real machine to software ​

You can say:

I start from the physical and operational reality of the machine. I identify stable concepts such as machine, subsystem, axis, station, recipe, operating mode, and workflow. Then I model them at the right level of abstraction. For example, I usually model motion in terms of axes and machine positions rather than raw motor channels, because that matches how the system reasons about movement. I also separate domain meaning from hardware integration details so the model remains understandable as devices change.

Common mistakes engineers make ​

You can mention:

  • modeling around screens instead of machine concepts
  • letting vendor SDK types leak into the domain
  • duplicating machine state across layers
  • creating too many generic abstractions too early
  • not defining clear ownership for state and responsibility
  • representing only data, with no domain behavior or invariants

What strong engineers do differently ​

Strong engineers:

  • learn the machine vocabulary deeply
  • model operational meaning, not just hardware inventory
  • choose abstractions that match real behavior
  • keep domain, workflow, and device concerns separate
  • define clear ownership of state
  • use names that survive hardware and UI changes
  • evolve the model intentionally as the machine grows

A concise interview answer ​

Good domain modeling in machine software means translating physical machine reality into stable software concepts. I want the code to reflect how the machine actually works: its subsystems, devices, positions, recipes, operating modes, and workflows. I avoid shaping the model around the database or UI. I also keep hardware integration details out of the domain as much as possible. That gives the system a consistent language, clearer ownership, lower coupling, and a much better chance of staying maintainable as the machine evolves.

Final mental model ​

Here is the simplest way to remember it:

text
Real machine
   ↓
Meaningful machine concepts
   ↓
Clear domain model
   ↓
Stable architecture
   ↓
More maintainable machine software

And the opposite is also true:

text
Unclear machine concepts
   ↓
Weak domain model
   ↓
Mixed responsibilities
   ↓
Fragile workflows and duplicated state
   ↓
Painful machine software

For industrial systems, domain modeling is not a cosmetic design exercise.

It is how you make the software think in the same shape as the machine.

That is what makes large machine systems understandable.

Source alignment: this fits the industrial software architecture emphasis on domain boundaries and long-term maintainability in hardware-heavy applications.

If you want, I can next do the same style for Stateful vs Stateless Components or Service vs Controller vs Workflow Responsibilities.

Docs-first project memory for AI-assisted implementation.

LCN Wafer Inspection Prototype