DDD Diego
“No decision may execute until its aggregate has attended strategic-design training.”
Does TPF come with a DDD language police badge?
Elevator answer
Yes. Call it a rule, policy, handler, or service. TPF needs clear inputs, outputs, effects, and an owner—not proof that the class has read the blue book.
3 coffee-machine misconceptions
Enterprise Edna
“Rename every service Capability and the business will become self-documenting.”
AI Ada
“Ask a model for ubiquitous language; accept its first twelve nouns.”
The real explanation
If the team says “eligibility rule,” making everyone rename it CustomerAdmissionDomainPolicy will not improve the rule. It will improve autocomplete's opinion of the architecture. TPF does not require a glossary exam before a payment can be declined.
What TPF requires is semantic clarity. A typed step has a coherent responsibility. A connector represents an actual I/O boundary. A pipeline has a meaningful input, outcome, and ownership story. Business logic is not silently defined by transport callbacks, and runtime behavior is not smuggled into a domain decision. Those needs exist whether a team uses the word aggregate or never utters it.
The framework fits a DDD-rich team and a pragmatic team. In the former, pipelines coordinate aggregates, policies, domain services, and domain events while leaving their language intact. In the latter, pipelines coordinate named business functions and explicit contracts without demanding that every function be classified by a pattern catalogue. The test is not vocabulary purity. It is whether a reader can tell what the step means, what it owns, and what happens when it crosses a boundary.
Refusing DDD terminology is not permission for HandleStuff to invoke ProcessThing and publish EventData. That has avoided jargon by avoiding meaning. If an engineer cannot say what enters the flow, what decision it makes, and what leaves, the business will not be rescued by a suffix.
TPF will not issue a citation because EligibilityRule is not called a domain service. It cares that the rule receives the right facts, that the external credit lookup is a Query rather than a hidden client call, and that the resulting Command fits the next step. Pattern theology remains optional.
The trade-off is that ambiguity cannot hide behind familiar framework names. A team may keep its language, but it must make that language precise enough for type contracts, mappings, and ownership to be reviewed. That is smaller than adopting doctrine and larger than naming every class Manager.
Trade-offs
TPF gains flexibility in domain style while retaining clear contracts. It gives up the ability to treat vague technical naming as architecture. Teams must invest in meaningful names even when they reject formal DDD vocabulary.
When TPF is not a good fit
TPF is not a good fit when a team wants all flow boundaries and responsibilities intentionally implicit. If no one can own a contract or name an outcome, a pipeline definition exposes that disagreement rather than solves it.