https://specdd.ai/how-to/software-design-practices/Spec-driven development software design guides for preserving boundaries, reducing coupling, focusing components, protecting APIs, and keeping domain rules in the right layer.Hugoen-ushttps://specdd.ai/how-to/software-design-practices/how-to-maintain-the-single-responsibility-principle-with-specdd/https://specdd.ai/how-to/software-design-practices/how-to-maintain-the-single-responsibility-principle-with-specdd/Maintain the Single Responsibility Principle with spec-driven development by writing local specs that define one purpose, owned files, required behavior, and explicit non-goals.https://specdd.ai/how-to/software-design-practices/how-to-separate-concerns-with-local-specs/https://specdd.ai/how-to/software-design-practices/how-to-separate-concerns-with-local-specs/Separate concerns with local SpecDD specs in a spec-driven development workflow by assigning each responsibility to the nearest owning spec and preventing overlap between modules, services, adapters, and components.https://specdd.ai/how-to/software-design-practices/how-to-define-and-enforce-module-and-architecture-boundaries-with-specs/https://specdd.ai/how-to/software-design-practices/how-to-define-and-enforce-module-and-architecture-boundaries-with-specs/Define and enforce module and architecture boundaries with spec-driven development by using ownership, allowed dependencies, forbidden access, inherited constraints, and review checks.https://specdd.ai/how-to/software-design-practices/how-to-prevent-cross-layer-coupling/https://specdd.ai/how-to/software-design-practices/how-to-prevent-cross-layer-coupling/Prevent cross-layer coupling with spec-driven development by defining allowed dependency direction, blocked layer access, adapter boundaries, and review checks.https://specdd.ai/how-to/software-design-practices/how-to-keep-ui-components-focused/https://specdd.ai/how-to/software-design-practices/how-to-keep-ui-components-focused/Keep UI components focused with SpecDD component specs for spec-driven development that define rendering, interaction, state, accessibility, and boundaries from domain and persistence logic.https://specdd.ai/how-to/software-design-practices/how-to-avoid-leaky-abstractions/https://specdd.ai/how-to/software-design-practices/how-to-avoid-leaky-abstractions/Avoid leaky abstractions with spec-driven development by defining public contracts, hiding implementation details, forbidding dependency leakage, and reviewing callers against the spec.https://specdd.ai/how-to/software-design-practices/how-to-design-testable-code-with-specs/https://specdd.ai/how-to/software-design-practices/how-to-design-testable-code-with-specs/Design testable code with spec-driven development by writing specs with observable behavior, clear boundaries, scenarios, dependencies, and Done when checks.https://specdd.ai/how-to/software-design-practices/how-to-define-interfaces-before-implementation/https://specdd.ai/how-to/software-design-practices/how-to-define-interfaces-before-implementation/Define interfaces before implementation with spec-driven development by specifying exposed entry points, accepted inputs, returned outputs, errors, examples, and boundaries.https://specdd.ai/how-to/software-design-practices/how-to-avoid-god-objects-and-god-modules/https://specdd.ai/how-to/software-design-practices/how-to-avoid-god-objects-and-god-modules/Avoid god objects and god modules with spec-driven development by limiting ownership, splitting responsibilities, adding non-goals, and keeping tasks local.https://specdd.ai/how-to/software-design-practices/how-to-split-large-features-into-small-safe-changes/https://specdd.ai/how-to/software-design-practices/how-to-split-large-features-into-small-safe-changes/Split large features into small safe changes with spec-driven development by decomposing behavior into local specs, sequencing tasks, and verifying each boundary.https://specdd.ai/how-to/software-design-practices/how-to-design-for-low-coupling-and-high-cohesion/https://specdd.ai/how-to/software-design-practices/how-to-design-for-low-coupling-and-high-cohesion/Design for low coupling and high cohesion with spec-driven development by grouping related responsibilities, minimizing dependencies, and enforcing local boundaries.https://specdd.ai/how-to/software-design-practices/how-to-write-specs-that-prevent-technical-debt/https://specdd.ai/how-to/software-design-practices/how-to-write-specs-that-prevent-technical-debt/Write SpecDD specs that prevent technical debt in a spec-driven development workflow by making boundaries, non-goals, dependencies, shortcuts, and completion criteria explicit.https://specdd.ai/how-to/software-design-practices/how-to-use-non-goals-to-prevent-the-wrong-work/https://specdd.ai/how-to/software-design-practices/how-to-use-non-goals-to-prevent-the-wrong-work/Use spec-driven development non-goals to prevent wrong work by writing focused Must not rules for plausible boundary mistakes, overreach, and responsibility leaks.https://specdd.ai/how-to/software-design-practices/how-to-compare-spec-driven-development-vs-tdd/https://specdd.ai/how-to/software-design-practices/how-to-compare-spec-driven-development-vs-tdd/Compare Spec-driven development and test-driven development, understand where specs and tests differ, and learn how to combine SpecDD with TDD.https://specdd.ai/how-to/software-design-practices/how-to-compare-spec-driven-development-vs-bdd/https://specdd.ai/how-to/software-design-practices/how-to-compare-spec-driven-development-vs-bdd/Compare Spec-driven development and behavior-driven development, understand how scenarios overlap, and learn how SpecDD adds ownership and boundaries.https://specdd.ai/how-to/software-design-practices/how-to-compare-specdd-specs-vs-architecture-docs/https://specdd.ai/how-to/software-design-practices/how-to-compare-specdd-specs-vs-architecture-docs/Compare SpecDD specs and architecture docs for spec-driven development, decide what belongs in each, and use source-adjacent specs to make architecture operational during code changes.https://specdd.ai/how-to/software-design-practices/how-to-keep-business-rules-in-the-domain-layer/https://specdd.ai/how-to/software-design-practices/how-to-keep-business-rules-in-the-domain-layer/Keep business rules in the domain layer with spec-driven development by assigning rule ownership, forbidding leakage into UI, controllers, jobs, and adapters, and reviewing checks.https://specdd.ai/how-to/software-design-practices/how-to-prevent-duplicate-logic-with-specs/https://specdd.ai/how-to/software-design-practices/how-to-prevent-duplicate-logic-with-specs/Prevent duplicate logic with spec-driven development by assigning one owner for validation, business rules, formatting, API behavior, and shared decisions.https://specdd.ai/how-to/software-design-practices/how-to-design-stable-public-apis-with-specs/https://specdd.ai/how-to/software-design-practices/how-to-design-stable-public-apis-with-specs/Design stable public APIs with spec-driven development by defining exposed endpoints, inputs, outputs, errors, compatibility rules, examples, and deprecation expectations.https://specdd.ai/how-to/software-design-practices/how-to-manage-dependency-direction-with-specs/https://specdd.ai/how-to/software-design-practices/how-to-manage-dependency-direction-with-specs/Manage dependency direction with spec-driven development by defining allowed imports, forbidden reverse dependencies, layer rules, and review checks.