The most important distinction in DAX is between a calculated column and a measure. A calculated column is evaluated row by row at refresh time, stored inside the model, and operates under row context. A measure is evaluated at query time inside the current filter context, typically aggregates values, and never bloats the model. Because measures compute on demand, they reflect whatever filters a visual or slicer applies. Best practice is to prefer measures whenever possible and reserve calculated columns for cases where you genuinely need the result as a slicer, filter, or row-level attribute.
Context in DAX comes in two flavors. Row context means "this current row," and it is created automatically by iterator functions such as SUMX, or when you write an expression inside a calculated column. Filter context is the set of filters currently applied to the model, originating from visuals, slicers, or the CALCULATE function. When you place a measure inside a calculated column, row context transitions into filter context: every column value on the current row becomes a filter on its respective table. This context transition is powerful but surprises beginners, and triggering it unnecessarily inside a calculated column is a common performance pitfall.
Basic measures are built from aggregation functions like SUM and DISTINCTCOUNT. SUM(Sales[Amount]) totals a column across the current filter context, while DISTINCTCOUNT(Sales[CustomerId]) counts unique customer identifiers. For division, prefer the DIVIDE function over the slash operator because DIVIDE handles a zero denominator gracefully by returning BLANK (or an optional third argument), whereas the slash operator produces an infinity error. Understanding these building blocks, plus the contrast between row and filter context, sets the stage for everything else in DAX.