⏱ 26 min read
Applying OOAD Principles in Modern Enterprise Architecture | Best Practices & Strategy Sparx EA best practices
Learn how Object-Oriented Analysis and Design (OOAD) principles strengthen modern enterprise architecture through modular design, scalability, maintainability, and better alignment between business and technology. how architecture review boards use Sparx EA
OOAD, Object-Oriented Analysis and Design, modern enterprise architecture, enterprise architecture principles, OOAD in enterprise architecture, modular system design, scalable architecture, maintainable software architecture, domain-driven design, architecture best practices, business and IT alignment, software design principles
Introduction
Object-Oriented Analysis and Design (OOAD) still has a place in modern enterprise architecture, but not because enterprises need more class diagrams or inheritance hierarchies. Its relevance now is more practical. OOAD gives architects a disciplined way to think about structure, behavior, ownership, and change.
In large organizations, architecture extends far beyond application code. It spans business capabilities, domain boundaries, data ownership, integration styles, platform services, security controls, and operating models. Within that broader landscape, OOAD remains useful because it helps architects design systems that are understandable, modular, and resilient under change. free Sparx EA maturity assessment
That value does not depend on treating every architectural element as a software object in the traditional sense. At enterprise scale, the “things” architects reason about are often business domains, services, workflows, policy components, platforms, or data products. The real test is whether those elements have clear responsibilities, well-defined interfaces, and behavior that belongs together. Seen this way, OOAD is less a coding technique than a design discipline. It prompts questions that matter just as much in distributed systems as they did in monoliths: What owns this behavior? Where should this rule live? Which interactions are necessary, and which ones create avoidable dependency?
Those questions matter more now because enterprise landscapes are more complex than they were when OOAD first became mainstream. Cloud platforms, APIs, event-driven integration, SaaS products, and continuous delivery have increased both the number of moving parts and the speed of change. They have also raised the cost of weak boundaries. Encapsulation supports service autonomy. Abstraction helps teams work across platform diversity without being buried in detail. Cohesion and low coupling improve how systems and teams are partitioned. Controlled substitution makes it possible to support regional, regulatory, or channel-specific variation without fragmenting the estate.
OOAD also remains relevant because enterprise architecture is fundamentally about making change manageable. Architects routinely decide whether a capability belongs in a shared platform, a domain service, or a local application; whether data should be governed centrally or within a domain context; and whether an integration should be synchronous, asynchronous, or event-driven. In one retail bank, for example, an architecture board approved a shared consent service but rejected a proposal for a shared onboarding workflow. Consent needed enterprise-wide consistency for regulatory reasons; onboarding varied too much by market, product, and channel to be centralized without creating friction. OOAD helps sharpen those calls by focusing attention on ownership, collaboration, and boundary integrity. multi-team Sparx EA collaboration
This article reframes OOAD for modern enterprise use and applies its principles across domain modeling, application, data and integration architecture, governance, and adoption. The central argument is straightforward: OOAD remains valuable not as a rigid methodology, but as a set of durable design lenses for building enterprise systems that can scale, adapt, and stay coherent over time.
1. Reframing OOAD for Enterprise Architecture
To use OOAD effectively today, it helps to move beyond its traditional association with application-level object modeling. In enterprise architecture, its real strength lies in helping architects reason about boundaries, responsibilities, interactions, and change across an entire landscape.
At this level, the concern is rarely confined to how classes collaborate inside a single codebase. Architects are deciding how business capabilities should be partitioned, which services should own which decisions, how data semantics should be protected, and how autonomous teams should collaborate without creating unnecessary dependency. The underlying OOAD questions remain the same, but the units of design are broader: domains, services, platforms, workflows, and data products rather than only software objects.
That shift matters because enterprise failure modes are broader as well. Inside one application, poor responsibility assignment may produce maintainability problems. Across an enterprise, the same mistake can lead to duplicated capabilities, conflicting data ownership, excessive integration complexity, and weak governance. OOAD helps reduce those risks by making responsibility and collaboration explicit. ARB governance with Sparx EA
Consider customer identity resolution. In many organizations, it belongs in an enterprise-level service because it demands consistency, policy control, and reuse across channels. A region-specific onboarding workflow, by contrast, is often better owned within a local domain solution, where variation can be managed without destabilizing the core identity model. The same pattern appears in IAM modernization. Central authentication, token policy, and privileged access controls are usually shared concerns; business-unit-specific approval steps for access requests may remain local. The distinction is simple but important: shared behavior and contextual behavior are not the same kind of concern, and they should not be designed as if they were.
The same is true of collaboration. Traditional OOAD focused on interaction among objects within a system. Modern enterprise architecture deals with interactions among autonomous services, event streams, human approvals, external partners, and packaged platforms. The mechanics are different, but the design concern is familiar. Interactions should be intentional, understandable, and aligned with responsibility boundaries. Sequence thinking, responsibility assignment, and collaboration modeling still matter, even when interactions are asynchronous and distributed rather than local and procedural.
This broader view also strengthens governance. Technology choices matter, but many long-term architecture problems stem from weak conceptual boundaries rather than from a poor choice of framework or cloud service. An OOAD-informed review asks whether a boundary is cohesive, whether an interface exposes stable business meaning, whether behavior sits close to the information and rules it depends on, and whether extension points have been designed deliberately. Those questions remain useful across technologies because they focus on structure and accountability rather than implementation fashion.
The rest of this article builds on that reframing. The next section outlines the principles that give OOAD its value at enterprise scale, and the sections that follow apply those principles to domain alignment, cross-layer architecture, governance, and adoption.
2. Core OOAD Principles and Their Architectural Significance
Once OOAD is treated as a discipline for architectural reasoning, its core principles become practical tests for whether an enterprise landscape will remain manageable as business needs evolve. Their value lies not in being uniquely object-oriented, but in helping architects localize change, preserve meaning, and reduce unnecessary dependency.
Abstraction
Abstraction allows architects to hide irrelevant detail while preserving what matters. Enterprise architecture operates across many levels at once: capability maps, domain models, application portfolios, integration contracts, and deployment platforms. Each level needs a view that is meaningful to its audience without exposing internal mechanics.
A business service, for example, should present a stable business purpose rather than expose database structures or workflow internals. A platform capability should describe what it enables and under what policies, not force every consuming team to understand how it is built. In a manufacturing group, a “production scheduling” capability may expose commitments, exceptions, and capacity windows while hiding whether the underlying implementation sits partly in SAP and partly in a custom optimization engine. That is abstraction doing useful work. It keeps the contract stable while allowing the implementation to evolve.
Strong abstraction also improves governance, because standards can be applied to interfaces and responsibilities rather than to every internal detail.
Encapsulation
Encapsulation protects autonomy by keeping behavior and the information it depends on inside a clear boundary. In enterprise systems, harmful coupling often appears when one team depends on another team’s internal data structures, process logic, or release timing. Encapsulation reduces that risk.
This principle directly supports service ownership, bounded contexts, and product-oriented delivery. If pricing logic is encapsulated within a pricing domain service, channel applications can consume pricing outcomes without embedding their own conflicting rules. That improves consistency, auditability, and change control.
A common counterexample appears in insurance. A claims portal may read policy tables directly from a core administration database because it seems faster than calling a policy service. That shortcut usually works until product rules change. Then the portal, the claims engine, and reporting extracts all interpret policy status differently. What looked like convenience turns into semantic drift and expensive reconciliation.
Cohesion and Modularity
Cohesion helps determine what belongs together. A cohesive component, service, or platform area exists for a clear reason and contains responsibilities that reinforce one another. Modularity then turns those cohesive units into understandable units of design and change.
This matters because enterprise sprawl often stems less from the number of systems than from the way responsibilities are separated. Shared platforms become overloaded with unrelated concerns, while local applications accumulate logic that should have been externalized or centralized. OOAD encourages architects to group behavior around meaningful business purpose rather than around organizational convenience or technical layering alone.
A customer communications platform is a useful example. If it owns message composition templates, channel routing, delivery preferences, and delivery audit, the boundary is coherent. If teams also push campaign segmentation, consent interpretation, and product eligibility into the same platform simply because “it already sends messages,” cohesion starts to erode.
Low Coupling
Low coupling reduces the blast radius of change. In enterprise architecture, coupling appears not only through direct API calls, but also through shared schemas, synchronized release cycles, duplicated assumptions, and hidden reliance on common definitions. OOAD highlights the need to minimize these dependencies so one domain or platform can evolve without destabilizing others.
Architects can apply this principle through contract-based interaction, event notification where appropriate, and anti-corruption mechanisms between domains that use different models. As later sections will show, this becomes especially important in integration architecture and governance for change.
Polymorphism and Controlled Substitution
At enterprise scale, polymorphism is less about language features than about controlled variation behind stable contracts. Different regions, brands, channels, or regulatory regimes may require different implementations of the same business capability. Rather than fragmenting the architecture, OOAD suggests defining stable interfaces with interchangeable implementations behind them.
This pattern is common in payment processing, tax calculation, identity verification, and notification services. A multinational retailer may expose a single “calculate tax” contract to commerce platforms while using different engines in the US, EU, and Gulf markets. The consuming applications should not need to know which jurisdiction-specific engine sits behind the interface. Their concern is the contract, not the internal variation.
Responsibility-Driven Design
Responsibility-driven design may be OOAD’s most important contribution at enterprise level. Many architectural failures begin with unclear ownership: data is mastered in multiple places, rules are scattered, and no component can be held accountable for outcomes. OOAD asks a simple but powerful question: who should own this behavior?
That question sharpens decisions about domain boundaries, platform services, and operating models. It also provides a practical test for architecture reviews. If no team can clearly state why a component exists, what decisions it owns, and what rules it enforces, the boundary is probably weak.
These principles become most useful when domain models reflect how the business actually creates value.
3. Aligning Domain Models with Business Capabilities and Value Streams
The principles above matter most when domain models reflect how the business works. In many enterprises, domain models are developed within projects, while capability maps and value streams are maintained separately as planning artifacts. When those views drift apart, the architecture may appear technically coherent while failing to support operational flow, accountability, or strategic change.
Business capabilities describe what the enterprise must be able to do, independent of current systems or reporting lines. Value streams describe how value is created and delivered through a sequence of outcomes, decisions, and handoffs. Domain models define the concepts, rules, and interactions that solutions must manage. The architectural challenge is to connect these perspectives so that domain boundaries are grounded in both business meaning and business motion.
Responsibility-driven design and cohesion are especially useful here. A sound domain boundary should own a coherent set of rules, decisions, and state transitions that support a business capability. It should also make sense within the flow of value delivery. If a domain cuts awkwardly across several value-stream stages or depends heavily on rules mastered elsewhere, that usually signals a poor boundary.
Take an order domain. It may reasonably own order capture, order lifecycle state, and customer-visible order status. Pricing, inventory, and fulfillment may remain separate domains that collaborate through explicit contracts. Folding all of these concerns into a single “commerce” model may simplify the picture, but it usually weakens cohesion and makes change harder. Separating them according to responsibility and interaction creates clearer ownership and more manageable collaboration.
The same logic appears in healthcare administration. A patient access domain may own registration, appointment intake, and eligibility capture, while a care authorization domain owns medical necessity decisions and approval status. Both participate in the same value stream, but they do not own the same behavior. Treating them as one domain because they both touch “patient onboarding” often produces confusion over who owns the rules that matter.
Capability and value-stream alignment also improves prioritization. Capability maps show where investment matters strategically, while value streams reveal where friction, delay, or duplication affects outcomes. Domain modeling can then focus on the concepts and interactions that materially influence business performance. Architects should ask which domain entities or aggregates are central to value realization, which events mark meaningful business progress, and which policies must remain consistent across channels. fixing Sparx EA performance problems
This analysis often clarifies where shared enterprise services are justified and where local variation should remain inside domain-specific solutions. Identity resolution or consent management may require enterprise consistency, while onboarding workflows or fulfillment exceptions may vary by geography or business line. The distinction is not ideological. It is a design choice based on where consistency creates value and where flexibility does.
Another benefit is clearer ownership. Capability-aligned domain models make it easier to assign stewardship for business rules, APIs, and data products. Value-stream alignment then shows how those assets contribute to broader end-to-end outcomes. That helps address a common enterprise problem: every system touches the process, but no team owns its integrity.
Perfect one-to-one mapping should not be expected. Some capabilities require several collaborating domains, and some value streams cross many bounded contexts. The goal is useful alignment, not rigid alignment. The architecture should correspond closely enough to business intent that it supports measurable outcomes and can evolve without repeated structural rework.
With domain boundaries grounded in business capabilities and value streams, the next step is to apply the same OOAD discipline across application, data, and integration architecture.
4. Applying OOAD Across Application, Data, and Integration Architecture
One of the most common enterprise weaknesses is inconsistency across architecture layers. Applications may be modular internally, while data ownership remains unclear and integrations reintroduce tight coupling. OOAD principles become far more effective when they are applied consistently across application architecture, data architecture, and integration architecture.
Application Architecture
In application architecture, OOAD guides how responsibilities are divided within and across solution components. The important question is not whether every application is implemented in a pure object-oriented style, but whether its internal structure reflects meaningful business behavior rather than technical convenience.
Enterprise applications often degrade into thin process layers over shared databases, or into collections of endpoints with little domain integrity. Responsibility-driven design and cohesion help prevent that. Components should be organized around use cases, decision logic, and lifecycle management so behavior is not scattered across user interfaces, orchestration scripts, and persistence code.
As noted in the previous section, application boundaries should reflect domain ownership. A well-designed application should make clear what it owns, which policies it enforces, and what it delegates to external services or platforms.
A practical example comes from telecom order management. A customer-facing order app may own order capture and amendment rules, but it should not also own network provisioning logic, tariff configuration, or credit policy simply because those checks occur during the same transaction. When those concerns remain in their proper domains, the application stays coherent and easier to evolve.
Data Architecture
In data architecture, OOAD clarifies the relationship between information and behavior. A common enterprise problem is treating data as a passive asset, detached from the rules that give it meaning. OOAD pushes in the opposite direction by asking which architectural element is responsible for maintaining the integrity of a business concept.
This has direct implications for master data, transactional consistency, and data product design. If a customer domain owns customer status, segmentation eligibility, and consent rules, downstream analytical or operational consumers should not redefine those semantics independently. When they do, encapsulation breaks down and semantic drift follows.
The earlier principles of encapsulation and low coupling are especially important here. Systems that author data, systems that reference it, and systems that derive views from it should not be treated as if they play the same role. Clear semantic ownership reduces duplication, improves stewardship, and makes governance easier to enforce.
In practice, this distinction matters in data platforms. A lakehouse may publish a “gold customer” dataset, but that does not make the data platform the owner of customer meaning. The customer domain remains accountable for the rules behind status, consent, and lifecycle state; the platform is responsible for distribution, quality controls, and access patterns.
Integration Architecture
In integration architecture, OOAD helps ensure that integrations express purposeful collaboration rather than accidental dependency. Many integration landscapes become brittle because interfaces are designed around payload movement instead of stable business interactions.
An OOAD-informed approach changes the conversation. Instead of asking only which fields need to be transferred, architects ask what business outcome is being requested, what state change is being announced, and which party is accountable for the response. This reflects the earlier emphasis on abstraction, responsibility, and low coupling.
That distinction matters in API-based and event-driven ecosystems. Poor contract design can spread internal assumptions across dozens of consuming systems. Better contracts preserve autonomy by exposing business meaning without leaking implementation detail. A Kafka-based event architecture, for example, works best when domains publish events such as OrderPlaced, ClaimApproved, or CustomerConsentUpdated with clear ownership and semantics, rather than using Kafka as a generic transport for internal database changes.
An airline provides a useful micro-example. If the reservation domain publishes SeatAssigned as a business event, downstream systems such as check-in, notifications, and loyalty can react appropriately. If it publishes raw seat-map table updates instead, every consumer must infer meaning from internal structures, and coupling spreads quickly.
Cross-Layer Consistency
A practical enterprise pattern is to apply OOAD differently, but consistently, at each layer:
- Application architecture uses it to organize behavior into cohesive components.
- Data architecture uses it to assign semantic ownership and protect integrity.
- Integration architecture uses it to shape contracts that preserve autonomy while enabling collaboration.
When these perspectives align, the architecture becomes more coherent. Teams know where logic belongs, data has an authoritative home, and interfaces remain more stable because they are based on business meaning rather than implementation leakage.
That cross-layer consistency also strengthens governance. Reviews can then test not only technical compliance, but also whether applications expose behavior they do not own, whether data stores are being misused as integration mechanisms, and whether interfaces bypass the domains responsible for key decisions.
5. Governance, Modularity, and Change Management
Enterprise architecture is tested less by the quality of its initial design than by how well it absorbs change over time. New regulations, acquisitions, operating model shifts, vendor replacements, and channel expansion all put pressure on existing structures. In that setting, OOAD contributes not only to design, but also to governance and change management.
Governance Through Structural Rules
Architecture governance often focuses too heavily on technology standards and too lightly on structural integrity. Yet many long-term failures begin with weak ownership, leaky interfaces, and uncontrolled dependency patterns. OOAD provides a stronger governance lens because it asks what should remain stable and what may vary.
A governance model informed by OOAD asks:
- Does each architectural building block have a clear purpose?
- Is its public contract separated from its internal implementation?
- Are dependencies aligned with intended domain relationships?
- Is behavior placed close to the information and policies it depends on?
- Are extension points deliberate rather than accidental?
These questions are more revealing than generic compliance checks because they expose structural weaknesses before those weaknesses spread across the portfolio. In practice, an architecture board might require a team to move entitlement rules out of a channel application and into a shared authorization service before approving rollout to additional markets. In another case, a board may allow three different case-management products to coexist temporarily, provided each sits behind a common case-status contract and no downstream system integrates directly to vendor-specific schemas.
Modularity as a Unit of Change
As discussed earlier under cohesion and encapsulation, modularity is not simply a matter of breaking systems into smaller pieces. In enterprise settings, it means creating units of change that can evolve semi-independently while still participating in a coherent whole.
A module may be a domain service, a platform capability, a packaged application boundary, or a governed data product. What matters is that it has explicit responsibilities and predictable interaction patterns. When modularity is defined in this way, portfolio decisions improve. Architects can retire, replace, outsource, or modernize parts of the estate with less uncertainty because the boundaries are meaningful rather than accidental.
This is particularly valuable during mergers and acquisitions. If customer communications, billing, and identity are already modularized as separate capabilities, an acquired business can be integrated selectively. Without those boundaries, consolidation tends to become an all-or-nothing exercise.
Change Management and Transition Planning
OOAD also improves change management by making dependencies visible and responsibility boundaries explicit. If business rules are concentrated in the components that own them, architects can assess which modules must change for a policy update and which should remain untouched. If variation points are designed intentionally, regional or product-line differences can be introduced without creating permanent forks in the architecture.
This is especially important in transition planning. Many enterprise changes fail not because the target architecture is wrong, but because the cost and risk of transition were underestimated. OOAD helps architects reason about impact, sequencing, and containment. A useful test is simple: if this capability changes, can the impact be contained within the boundary that claims to own it?
That question is practical, not theoretical. If a new privacy regulation requires changes to consent withdrawal rules, and six channels plus three reporting platforms all implement their own versions of that logic, the problem is architectural before it is technical.
Federated Governance
Large enterprises rarely operate through centralized control over every solution decision. Governance therefore has to scale across teams, technologies, and delivery models. OOAD principles such as responsibility, encapsulation, cohesion, and controlled extension work well in federated governance because they can be applied locally while still preserving enterprise integrity.
This shifts governance away from prescribing every implementation detail and toward enforcing architectural quality through durable principles. Teams keep their autonomy, but not at the expense of conceptual coherence. The same approach is useful in technology lifecycle governance. For example, setting a policy that legacy identity brokers move from tolerate to retire over 18 months works far better when replacement boundaries and responsibilities are already clear.
The practical implications become even clearer when translated into repeatable patterns and recognizable anti-patterns.
6. Patterns, Anti-Patterns, and Adoption in Real Enterprises
OOAD becomes most useful in enterprise architecture when it is translated into repeatable patterns and recognizable failure modes. Most architects understand abstraction and encapsulation in theory. The harder task is spotting when those principles are being applied well across delivery teams, vendor products, cloud services, and legacy constraints.
Effective Patterns
Domain Façade with Internal Complexity Hidden
One strong enterprise pattern is the domain façade: a business domain coordinates multiple internal components, rules engines, and data sources, but exposes a stable, business-oriented API or event model.
Its value goes beyond a cleaner interface. It protects downstream systems from internal restructuring and allows the owning team to evolve implementation details without renegotiating every dependency. That is particularly useful in incremental modernization, where internal complexity may remain mixed for years. A bank replacing part of its lending stack, for instance, may still expose a stable “loan decision” interface while internally routing requests across a legacy scoring engine, a new rules service, and a manual review queue.
Policy Encapsulation
Another important pattern is policy encapsulation. Rules for pricing, eligibility, compliance, entitlement, or risk are often scattered across channels and applications. OOAD-aligned architecture concentrates that logic into explicit policy services or domain-owned decision components.
This improves auditability and reduces the familiar problem of the “same rule, different outcome” across business units. It also reflects a broader architectural principle: behavior should sit close to the information and rules it depends on.
Controlled Variation Through Strategy and Adapters
A third pattern is controlled variation behind stable contracts. Large organizations often need regional, brand, or partner-specific behavior while preserving a common operating model. Rather than cloning systems or embedding conditional logic throughout the estate, architects can define a stable capability contract and allow controlled substitution behind it.
This pattern is particularly effective for payment providers, tax engines, notification channels, and identity verification services. It applies the principle of polymorphism at architectural scale and supports variation without hidden fragmentation.
Common Anti-Patterns
Anemic Service Boundaries
A frequent anti-pattern is the anemic service boundary, where a service exposes data but owns little real behavior. These services may look modular on architecture diagrams, yet they force orchestration layers or consuming applications to reconstruct business rules elsewhere. The result is distributed coupling disguised as decomposition.
This violates responsibility-driven design. If a service owns no meaningful behavior, it is often not a true domain boundary.
Imposed Canonical Model Everywhere
Another anti-pattern is the shared enterprise object model imposed everywhere. Standardization has its place, but forcing one canonical model across all domains often suppresses meaningful differences and creates brittle integration. Some concepts do need to be shared, but many require translation between contexts rather than strict uniformity.
This is where low coupling and abstraction matter. Shared meaning should be established where necessary, but contextual models should remain free to reflect domain-specific realities.
Inheritance-Driven Architecture Thinking
A further anti-pattern is inheritance-driven architecture thinking, in which teams create rigid hierarchies of platforms, services, or business entities in pursuit of reuse. At enterprise scale, this often produces overgeneralized designs that become difficult to change because every exception threatens the hierarchy.
Composition and explicit contracts are usually more resilient than abstract taxonomies designed too early. That is especially true in enterprises where variation is inevitable.
Adoption Considerations
Real-world adoption depends as much on operating conditions as on design quality. Team maturity, funding models, vendor constraints, and delivery pressure all shape what is feasible. OOAD-aligned patterns succeed when ownership is real: a team must be accountable for the behavior behind a contract, not merely for publishing an interface.
Likewise, anti-patterns often emerge when governance rewards standardization slogans over domain clarity, or when project timelines encourage direct data access instead of proper boundary design. For that reason, architects should assess adoption pragmatically. The real question is not whether the enterprise is “doing OOAD,” but whether its design choices create stable responsibilities, manageable variation, and contracts that can survive organizational and technical change.
Conclusion
OOAD remains valuable in modern enterprise architecture because it sharpens architectural judgment in environments defined by scale, distribution, and continuous change. Its importance does not lie in preserving an older design style, but in offering durable ways to decide where behavior belongs, how boundaries should be drawn, and how variation should be managed.
As the earlier sections have shown, OOAD’s strongest contribution is conceptual discipline. Reframed for enterprise use, it helps architects reason about responsibility, abstraction, encapsulation, cohesion, coupling, and controlled substitution across domains, platforms, data, and integrations. Those principles are not limited to application design; they shape how enterprises align architecture with business capabilities, assign ownership, govern change, and avoid fragmentation.
This is especially relevant for organizations pursuing domain-based operating models, platform engineering, event-driven integration, IAM modernization, and hybrid cloud strategies. In such environments, speed can easily outpace structural coherence. OOAD offers a way to preserve that coherence without becoming dogmatic. It supports selective, explicit, outcome-driven design: use the principle that improves clarity, ownership, and adaptability, and avoid forcing every problem into a rigid object model.
A practical test remains simple: if a capability changes, can the impact be contained within the boundary that claims to own it? If not, the architecture likely needs refinement regardless of the technologies involved. That question captures why OOAD still matters. At enterprise scale, good architecture is not just about decomposition; it is about making change intelligible, governable, and survivable.
Used in this way, OOAD is not a legacy methodology. It is a durable set of design lenses for building enterprise systems that can scale, evolve, and remain coherent over time.
Frequently Asked Questions
What is Object-Oriented Analysis and Design (OOAD)?
OOAD is a software engineering approach that models systems as interacting objects with defined responsibilities, attributes, and behaviours. It uses UML as its primary notation — class diagrams for structure, sequence diagrams for behaviour, and state machines for lifecycle. OOAD principles like encapsulation, inheritance, and polymorphism guide sound domain model design.
How do OOAD principles apply to enterprise architecture?
OOAD principles inform EA by encouraging loose coupling (systems should depend on interfaces, not implementations), high cohesion (each component should have a clear, bounded responsibility), and composition over inheritance (prefer composable services over deep inheritance hierarchies). These principles underpin microservices, domain-driven design, and API contract design.
What is the Liskov Substitution Principle in enterprise design?
The Liskov Substitution Principle (LSP) states that a subtype must be substitutable for its parent type without breaking the system. In enterprise design, this means that when you extend a service, capability, or component, the extension must honour all contracts of the original. Violations create fragile inheritance hierarchies and surprise consumers.