maios-software-designlisted

# Design responsibilities that carry useful behavior Begin with the work a caller or participant needs to accomplish, the behavior that must remain coherent and the effects it must understand. File proximity, name symmetry and anticipated reuse do not by themselves define a useful module. ## Find the responsibility before the interface Understand which decisions the proposed boundary should own, which state and dependencies it can encapsulate and which errors, progress or effects must remain visible. If every caller still coordinates the internal implementation, a thin wrapper may have changed names without reducing complexity. Explore another materially different organization when it can expose a missing tradeoff. A command-oriented interface and a result-oriented one, for example, may distribute responsibility differently. Compare the knowledge required of callers, invalid states, recovery, likely change and migration burden. Do not manufacture two designs when the relation is already settled. ## Preserve truthful depth A useful interface lets callers express their work without inheriting unnecessary storage, framework or transport detail. Keep domain decisions with the owner that understands them. Do not hide a consequential effect behind an apparently harmless operation. Classify dependencies through their actual behavior. Pure transformation, owned persistent state and an external service create different failure and recovery relationships. A generic port should n