7a:T62e,In software engineering, a **concern** is any piece of interest or focus in a program. More precisely, it is a distinct aspect of functionality that can be identified, discussed, and potentially isolated from other aspects. The term was popularized by Edsger W. Dijkstra in his seminal 1974 paper "On the role of scientific thought," where he introduced the concept of **separation of concerns** as a fundamental principle of program organization. **Dijkstra's Original Insight:** > *"Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained—on the contrary!—by tackling these various aspects simultaneously. It is what I sometimes have called 'the separation of concerns', which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts."* This insight remains as powerful today as when it was written. A concern represents a **coherent area of interest** that can be reasoned about independently—even though in the final system, all concerns must work together harmoniously.7b:T721,// A seemingly simple function that actually addresses many concerns async function createOrder(request: CreateOrderRequest): Promise { // CONCERN: Input Validation // Ensuring data meets structural and semantic requirements validateOrderRequest(request); // CONCERN: Authentication // Verifying the identity of the requester const user = await authenticateRequest(request.token); // CONCERN: Authorization // Determining if the authenticated user can perform this action await authorizeOrderCreation(user, request); // CONCERN: Business Logic / Domain Rules // Applying domain-specific calculations and validations const orderTotal = calculateOrderTotal(request.items); const discounts = applyDiscountRules(orderTotal, user); const finalTotal = orderTotal - discounts; // CONCERN: Inventory Management // Checking and reserving stock await reserveInventory(request.items); // CONCERN: Persistence // Storing data durably const order = await orderRepository.save({ userId: user.id, items: request.items, total: finalTotal, status: 'pending' }); // CONCERN: External Integration // Communicating with payment provider await paymentService.authorize(order.id, finalTotal); // CONCERN: Event Publishing / Notification // Informing other parts of the system await eventBus.publish('order.created', { orderId: order.id }); // CONCERN: Logging / Observability // Recording what happened for debugging and analytics logger.info('Order created', { orderId: order.id, userId: user.id }); // CONCERN: Response Formatting / Presentation // Preparing the output for the caller return formatOrderResponse(order); }7c:T565,// SYSTEM LEVEL: Entire products/platforms // - OrderingSystem // - InventorySystem // - PaymentGateway // SUBSYSTEM LEVEL: Bounded contexts within a product namespace OrderingContext { // Everything related to orders class OrderService { /* ... */ } class OrderRepository { /* ... */ } class OrderEvents { /* ... */ } } namespace PaymentContext { // Everything related to payments class PaymentService { /* ... */ } class PaymentRepository { /* ... */ } class PaymentEvents { /* ... */ } } // COMPONENT LEVEL: Services within a bounded context class OrderService { constructor( private validator: OrderValidator, // Validation concern private calculator: PriceCalculator, // Calculation concern private repository: OrderRepository, // Persistence concern private events: OrderEventPublisher // Event concern ) {} } // ASPECT LEVEL: Cross-cutting concerns // Applied via decorators/middleware @Transactional() @Logged() @Cached({ ttl: 300 }) async getOrderById(id: string): Promise { ... } // METHOD LEVEL: Single operations class PriceCalculator { calculateBasePrice(items: Item[]): Money { /* focused logic */ } applyDiscounts(price: Money, discounts: Discount[]): Money { /* focused logic */ } applyTax(price: Money, region: Region): Money { /* focused logic */ } }7d:T40d,// FP: Functions represent concerns as pure transformations // Each function handles one concern // Validation concern (pure) const validateOrder = (order: Order): Either => { const errors = [ validateItems(order.items), validateCustomer(order.customer), validateShipping(order.shipping) ].filter(isError); return errors.length > 0 ? left(errors) : right(order); }; // Calculation concern (pure) const calculateTotal = (order: Order): OrderWithTotal => ({ ...order, total: order.items.reduce((sum, item) => sum + item.price * item.quantity, 0) }); // Discount concern (pure) const applyDiscounts = (order: OrderWithTotal): OrderWithTotal => ({ ...order, total: order.total * (1 - getDiscountRate(order)) }); // Composition: pipeline of concerns const processOrder = pipe( validateOrder, map(calculateTotal), map(applyDiscounts), chain(persistOrder), // Side effect isolated chain(sendNotification) // Side effect isolated );7e:T450,// AOP: Cross-cutting concerns declared separately from business logic // Business logic - clean and focused class OrderService { async createOrder(order: Order): Promise { const validated = this.validator.validate(order); const priced = this.calculator.calculateTotal(validated); return this.repository.save(priced); } } // Cross-cutting concerns declared as aspects @Aspect() class LoggingAspect { @Before('execution(* OrderService.*(..))') logEntry(jp: JoinPoint) { console.log(`Entering ${jp.methodName} with args: ${jp.args}`); } @After('execution(* OrderService.*(..))') logExit(jp: JoinPoint) { console.log(`Exiting ${jp.methodName}`); } } @Aspect() class TransactionAspect { @Around('execution(* *Repository.save(..))') wrapInTransaction(jp: JoinPoint) { const tx = this.transactionManager.begin(); try { const result = jp.proceed(); tx.commit(); return result; } catch (e) { tx.rollback(); throw e; } } }7f:T677,async function handleUserRegistration(req: Request, res: Response) { // What concerns can you identify here? const startTime = Date.now(); const { email, password, name } = req.body; if (!email || !email.includes('@')) { return res.status(400).json({ error: 'Invalid email' }); } if (!password || password.length < 8) { return res.status(400).json({ error: 'Password too short' }); } try { const existing = await db.users.findOne({ email }); if (existing) { return res.status(409).json({ error: 'Email already registered' }); } const hashedPassword = await bcrypt.hash(password, 10); const user = await db.users.insert({ email, password: hashedPassword, name, createdAt: new Date() }); const token = jwt.sign({ userId: user.id }, SECRET, { expiresIn: '24h' }); await sendEmail({ to: email, subject: 'Welcome!', body: `Welcome to our platform, ${name}!` }); await analytics.track('user.registered', { userId: user.id }); console.log(`User ${email} registered in ${Date.now() - startTime}ms`); res.cookie('authToken', token, { httpOnly: true }); res.status(201).json({ user: { id: user.id, email, name } }); } catch (error) { console.error('Registration failed:', error); await alerting.notify('registration-failure', error); res.status(500).json({ error: 'Registration failed' }); } }72:{"json":{"id":"seed_0e997b34ce7139995e9c353b35bd22ea","slug":"separation-of-concerns","category":"System Design (HLD)","topic":"Separation of Concerns","title":"Separation of Concerns","description":"Master the art of decomposing software systems into focused, manageable units. Learn to identify, isolate, and manage distinct concerns—from business logic to cross-cutting aspects—creating systems that are maintainable, testable, and resilient to change.","difficulty":"INTERMEDIATE","estimatedMinutes":75,"pages":[{"id":"seed_21d296f978f79f79b5695851819f12dd","title":"Identifying Concerns","order":0,"content":[{"id":"opening-hook","title":"The Essence of Software Decomposition","content":[{"data":{"content":"Every software system, regardless of its size or complexity, is a tapestry woven from distinct threads of functionality. A web application simultaneously handles **user authentication**, **data validation**, **business logic**, **persistence**, **logging**, **error handling**, and **presentation**. Each of these represents a different *concern*—a distinct area of responsibility within the system.\n\nThe ability to recognize and articulate these concerns is the first step toward building software that remains comprehensible and malleable throughout its lifecycle. Without this recognition, systems become tangled masses where every change requires understanding everything at once, and modifying one feature inadvertently breaks another."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand what constitutes a 'concern' in software design, develop techniques for identifying concerns in any system, and learn to distinguish between different types of concerns. This foundational skill enables every subsequent principle of separation—you cannot separate what you cannot see.","variant":"info"},"type":"callout"}]},{"id":"what-is-a-concern","title":"What Is a Concern?","content":[{"data":{"content":"$7a"},"type":"text"},{"data":{"items":["**Coherence** — A concern represents a unified, logically related set of behaviors or data. Everything within the concern 'belongs together' in a meaningful way.","**Identifiability** — A concern can be named and discussed. If you can't articulate what a concern is about, it may not be a genuine concern but rather an undefined mixture.","**Distinct Purpose** — A concern serves a specific purpose that differs from other concerns. While concerns may interact, each addresses a different fundamental question or responsibility.","**Potential for Isolation** — At least in principle, a concern could be developed, tested, or modified without deep entanglement with other concerns (though full isolation isn't always practical).","**Stable Boundary** — Over time, the boundary of a well-identified concern remains relatively stable, even as implementation details evolve."],"title":{"icon":"Target","text":"Essential Characteristics of a Concern","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"Info","title":"Concerns Are Not Always Obvious","content":"Identifying concerns is an analytical skill that develops with experience. A junior developer might see a monolithic 'handle user request' function. A senior developer sees authentication, authorization, validation, business logic, persistence, and response formatting—each a distinct concern waiting to be recognized.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"categories-of-concerns","title":"Categories of Concerns","content":[{"data":{"content":"Concerns manifest at different levels and serve different purposes within software systems. Understanding these categories helps you systematically analyze any system and ensure you haven't overlooked important aspects.\n\n**Functional vs Non-Functional Concerns:**\n\nThe most fundamental distinction is between concerns that define *what* the system does versus *how well* it does it:"},"type":"text"},{"data":{"rows":[["Functional Concerns","What the system does—its features and capabilities","User registration, payment processing, order fulfillment, report generation","What actions can users perform? What data transformations occur?"],["Non-Functional Concerns","How well the system performs its functions—quality attributes","Performance, security, reliability, scalability, usability, maintainability","How fast? How secure? How available? How easy to modify?"]],"caption":"Functional vs Non-Functional Concerns","headers":["Category","Definition","Examples","Typical Questions"]},"type":"table"},{"data":{"content":"**Domain Concerns vs Technical Concerns:**\n\nAnother critical distinction separates concerns related to the problem domain from concerns related to the technical solution:"},"type":"text"},{"data":{"left":[{"data":{"items":["**Business rules** — How the domain works (e.g., 'orders over $100 get free shipping')","**Domain entities** — Core concepts like Customer, Order, Product, Account","**Domain services** — Operations meaningful in the business context (e.g., 'process refund')","**Workflows** — Business processes that span multiple operations","**Policies** — Business decisions encoded as logic (pricing, eligibility, etc.)"],"title":{"icon":"Briefcase","text":"Domain Concerns","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**Persistence** — How data is stored and retrieved (databases, files)","**Communication** — How components exchange data (HTTP, messaging)","**Infrastructure** — Deployment, scaling, monitoring capabilities","**Presentation** — How information is displayed to users (UI/UX)","**Integration** — How external systems are connected and managed"],"title":{"icon":"Cpu","text":"Technical Concerns","type":"icon","color":"secondary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"icon":"Lightbulb","title":"The Volatility Principle","content":"Domain concerns and technical concerns typically change for different reasons and at different rates. Business rules evolve with market conditions; infrastructure concerns change with technology choices. Separating them means that replacing your database doesn't require rewriting your business logic, and changing a business rule doesn't require understanding your caching strategy.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"core-application-concerns","title":"Core Application Concerns","content":[{"data":{"content":"While every application has unique functional requirements, certain concerns appear so consistently across software systems that they form a common vocabulary for engineers. Recognizing these patterns accelerates your ability to analyze new systems and communicate with other developers.\n\n**The Universal Concerns:**\n\nConsider a typical web application processing a user request. Even in a simple CRUD operation, numerous concerns are involved:"},"type":"text"},{"data":{"code":"$7b","fileName":"concerns-in-action.ts","language":"typescript"},"type":"code"},{"data":{"content":"The code above is instructive but **problematic** from a separation of concerns perspective. All these concerns are intertwined in a single function, making it difficult to:\n\n- **Test** any single concern in isolation\n- **Modify** one concern without risking others\n- **Reuse** individual concerns in other contexts\n- **Understand** what the function does at a glance\n\nRecognizing these concerns is the first step. Later in this module, we'll learn techniques to isolate them."},"type":"text"},{"data":{"items":["**Input Handling** — Parsing, deserializing, and validating incoming data before it enters the system","**Authentication** — Verifying identity claims (who is making the request)","**Authorization** — Enforcing access control (what are they allowed to do)","**Business Logic** — Core domain rules and calculations that define the system's purpose","**Data Access** — Reading from and writing to persistent storage","**Caching** — Storing computed results to avoid redundant work","**Transaction Management** — Ensuring atomicity and consistency of state changes","**Error Handling** — Detecting, categorizing, and responding to failures","**Logging** — Recording events for debugging, auditing, and analytics","**Metrics / Monitoring** — Measuring system behavior for operational visibility","**Event Publishing** — Notifying other components or systems of state changes","**Output Formatting** — Transforming internal data into appropriate output formats"],"title":{"icon":"Layers","text":"Catalog of Common Concerns","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"}],"titleType":"number","titleNumber":3},{"id":"techniques-for-identifying","title":"Techniques for Identifying Concerns","content":[{"data":{"content":"Identifying concerns is part analysis, part intuition—and it improves dramatically with practice. The following techniques provide systematic approaches to uncovering concerns in any system.\n\n**Technique 1: The 'Why' Chain**\n\nFor any piece of code or functionality, ask 'Why does this exist?' repeatedly until you reach a fundamental purpose. Each distinct answer often reveals a separate concern.\n\n*Example:* Why does this line validate the email format?\n→ To ensure data quality (Input Validation concern)\n→ Why ensure data quality? To prevent errors later (Error Prevention concern)\n→ Why prevent errors? To maintain system integrity (Data Integrity concern)\n\nEach level reveals a different aspect that might warrant separate consideration."},"type":"text"},{"data":{"code":"// Original mixed concern code\nfunction processPayment(payment: Payment) {\n // Why? To ensure the amount is valid (VALIDATION)\n if (payment.amount <= 0) throw new Error(\"Invalid amount\");\n \n // Why? To track what happened (LOGGING)\n console.log(`Processing payment: ${payment.id}`);\n \n // Why? To check user permission (AUTHORIZATION)\n if (!payment.user.canMakePayments) throw new Error(\"Not authorized\");\n \n // Why? To persist the payment record (PERSISTENCE)\n database.save(payment);\n \n // Why? To communicate with payment provider (INTEGRATION)\n stripeClient.charge(payment.amount, payment.user.card);\n \n // Why? To inform other systems (EVENTING)\n eventBus.emit('payment.processed', payment);\n}\n\n// Each \"Why?\" answer points to a distinct concern that could be separated","fileName":"why-chain-analysis.ts","language":"typescript"},"type":"code"},{"data":{"content":"**Technique 2: The Stakeholder Lens**\n\nDifferent stakeholders care about different aspects of a system. Viewing the system through each stakeholder's perspective reveals concerns that might otherwise be invisible:\n\n- **End Users** see features, usability, performance\n- **Business Owners** see revenue, compliance, competitive advantage\n- **Operations Teams** see deployability, monitoring, incident response\n- **Developers** see maintainability, testability, architectural clarity\n- **Security Teams** see vulnerabilities, access control, audit trails\n- **Data Teams** see data quality, analytics, privacy compliance\n\nEach stakeholder perspective illuminates different concerns."},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Change Driver Test","content":"Ask: 'What different forces might cause this code to change?' Each distinct force typically represents a distinct concern. If marketing requirements, database schema changes, and regulatory updates could all modify the same code, you have multiple concerns entangled. Well-separated concerns change for a single reason each.","variant":"tip"},"type":"callout"},{"data":{"content":"**Technique 3: The Verbal Description Test**\n\nDescribe what a component does in plain English. If you find yourself using the word **'and'** frequently, you're likely describing multiple concerns:\n\n*Poor (multiple concerns):* \"This class handles user registration **and** sends welcome emails **and** logs the new user **and** validates email uniqueness.\"\n\n*Better (focused concerns):*\n- \"This class orchestrates the user registration process.\"\n- \"This class sends templated emails to users.\"\n- \"This class validates email uniqueness against the database.\"\n- \"This class logs significant user events.\"\n\nEach simple description points to a single concern."},"type":"text"},{"data":{"items":["Can you name this functionality in 2-3 words? If not, it may be multiple concerns.","Would this functionality make sense in a different application? Universal applicability often indicates a separable concern.","Does this functionality change for a single, identifiable reason? Multiple change drivers suggest multiple concerns.","Can you imagine testing this aspect independently? Testability indicates separability.","Would a different team member naturally own this? Organizational ownership often aligns with concerns.","Does this functionality have its own vocabulary or domain terms? Distinct terminology suggests a distinct concern."],"title":{"icon":"Search","text":"Concern Identification Checklist","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":4},{"id":"granularity-of-concerns","title":"Granularity of Concerns","content":[{"data":{"content":"Concerns exist at multiple levels of granularity. A common mistake is applying separation of concerns at too fine or too coarse a level. Understanding the hierarchy of concerns helps you make appropriate decisions about where to invest in separation.\n\n**Concern Hierarchy:**\n\nConcerns can be analyzed at progressively finer levels of detail:"},"type":"text"},{"data":{"rows":[["System","Entire product or platform","E-commerce vs CMS vs Analytics","Separate systems, APIs, deployments"],["Subsystem/Bounded Context","Major functional area","Ordering, Inventory, Payments, Shipping","Microservices, modules, packages"],["Component/Service","Coherent functional unit","Order validation, price calculation, notification","Classes, services, functions"],["Aspect","Cross-cutting behavior","Logging, security, transaction management","Aspects, middleware, decorators"],["Method/Function","Single operation","Calculate discount, format date, validate email","Functions, private methods"]],"caption":"Levels of Concern Granularity","headers":["Level","Scope","Examples","Typical Separation Mechanism"]},"type":"table"},{"data":{"code":"$7c","fileName":"granularity-examples.ts","language":"typescript"},"type":"code"},{"data":{"icon":"AlertCircle","title":"Finding the Right Granularity","content":"Too fine-grained separation creates fragmentation—dozens of tiny classes that individually make no sense. Too coarse-grained separation fails to achieve any real separation—a few massive classes with everything tangled together. The right granularity is where each unit has a clear, coherent purpose and changes for a single reason. This is art as much as science.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"concerns-in-paradigms","title":"Concerns Across Programming Paradigms","content":[{"data":{"content":"The concept of concerns transcends any specific programming paradigm, but different paradigms offer different mechanisms for expressing and separating concerns.\n\n**Object-Oriented Programming:**\n\nOOP provides classes and interfaces as the primary mechanism for separating concerns. Each class ideally represents a single concern, and interfaces define the contracts between concerns:"},"type":"text"},{"data":{"code":"// OOP: Classes encapsulate concerns\ninterface OrderRepository {\n save(order: Order): Promise; // Persistence concern\n findById(id: string): Promise;\n}\n\ninterface PaymentProcessor {\n process(amount: Money): Promise; // Payment concern\n}\n\ninterface NotificationService {\n notify(user: User, message: Message): Promise; // Notification concern\n}\n\n// Concerns are composed via dependency injection\nclass OrderService {\n constructor(\n private repository: OrderRepository,\n private payment: PaymentProcessor,\n private notifications: NotificationService\n ) {}\n \n async createOrder(order: Order): Promise {\n // This method orchestrates but doesn't implement the concerns\n await this.repository.save(order);\n await this.payment.process(order.total);\n await this.notifications.notify(order.user, orderConfirmation(order));\n }\n}","fileName":"oop-concerns.ts","language":"typescript"},"type":"code"},{"data":{"content":"**Functional Programming:**\n\nFP separates concerns through pure functions and composition. Each function addresses a single transformation, and concerns are separated by avoiding side effects:"},"type":"text"},{"data":{"code":"$7d","fileName":"fp-concerns.ts","language":"typescript"},"type":"code"},{"data":{"content":"**Aspect-Oriented Programming:**\n\nAOP provides explicit mechanisms for separating cross-cutting concerns (those that span multiple components) from primary logic:"},"type":"text"},{"data":{"code":"$7e","fileName":"aop-concerns.ts","language":"typescript"},"type":"code"},{"data":{"icon":"Info","title":"Paradigm Agnostic Principle","content":"Regardless of paradigm, the goal remains the same: organize code so that each piece has a clear, single purpose and can be understood, modified, and tested in relative isolation. The paradigm provides the tools; the principle guides their use.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"practical-exercises","title":"Identifying Concerns: Practical Exercises","content":[{"data":{"content":"Let's apply what we've learned to analyze real code and identify its concerns. These exercises build the analytical muscle needed for effective separation.\n\n**Exercise 1: The God Function**\n\nExamine the following function and identify all distinct concerns:"},"type":"text"},{"data":{"code":"$7f","fileName":"exercise-god-function.ts","language":"typescript"},"type":"code"},{"data":{"type":"ordered","items":["**Request Parsing** — Extracting data from the HTTP request body","**Input Validation** — Checking email format and password length","**Uniqueness Verification** — Checking if email is already registered","**Password Security** — Hashing passwords before storage","**User Persistence** — Storing the user in the database","**Token Generation** — Creating an authentication JWT","**Email Notification** — Sending the welcome email","**Analytics Tracking** — Recording the registration event","**Performance Logging** — Timing and logging the operation","**Response Formatting** — Setting cookies and JSON response","**Error Handling** — Catching and responding to failures","**Alerting** — Notifying operations of failures"],"title":{"icon":"CheckSquare","text":"Concerns in the Registration Function","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"Lightbulb","title":"The Separation Challenge","content":"Notice how this 'simple' function embeds 12+ distinct concerns in roughly 50 lines. Each concern could change independently: validation rules might evolve, email templates might change, analytics providers might switch. Yet they're all tangled together. In the next pages, we'll learn techniques for isolating these concerns, making each one testable and modifiable on its own.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Identifying Concerns","content":[{"data":{"content":"Identifying concerns is the foundational skill for separation of concerns. Before you can separate, you must see. Let's consolidate what we've learned:"},"type":"text"},{"data":{"type":"ordered","items":["**A concern is a coherent area of interest** — any distinct aspect of functionality that can be identified, named, and discussed independently.","**Concerns exist in categories** — functional vs non-functional, domain vs technical. Each category brings different considerations.","**Common concerns recur across systems** — authentication, validation, persistence, logging, and others appear in nearly every application.","**Use systematic techniques** — the 'Why' chain, stakeholder lens, change driver test, and verbal description test help uncover hidden concerns.","**Granularity matters** — concerns exist at system, subsystem, component, aspect, and method levels. Choose appropriate granularity for separation.","**Programming paradigms offer different tools** — OOP uses classes, FP uses pure functions, AOP uses aspects. The principle transcends the mechanism."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nNow that we can identify concerns, the next page explores **Isolating Concerns**—the techniques and patterns for actually achieving separation in code. We'll learn how to structure systems so that each concern lives in its own space, interacting with others through well-defined boundaries."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand what concerns are and how to identify them systematically. This analytical skill is the foundation for all separation of concerns work—you can't separate what you can't see. In the next page, we'll learn how to translate this understanding into structured, well-organized code.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_275c37295285f84cf0f0aa29b9ac48e6","title":"Isolating Concerns","order":1,"content":null,"isLocked":true},{"id":"seed_341f66aa32c8cbaf66926b0514ad732f","title":"Cross-Cutting Concerns","order":2,"content":null,"isLocked":true},{"id":"seed_835298ae287a4c4dc915d09b3b90cd27","title":"Concern Separation in Architecture","order":3,"content":null,"isLocked":true}]}}