I85PREP
⌘ K
ODC Architecture Specialist study materials
ODC Architecture Specialist study resources

ODC Architecture Specialist practice questions

One question at a time. Build your ODC Architecture Specialist understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Architecture Design Fundamentals

In OutSystems Developer Cloud (ODC), why should an application be split into multiple modules rather than built as one large module?

  1. To allow each module to run in a different ODC stage automatically.
  2. To isolate responsibilities and expose only intended public elements for reuse. Correct answer.
  3. To eliminate the need for deployment pipelines between stages.
  4. To ensure every module can be deployed independently as a separate app.

Explanation

Multiple modules support separation of concerns and encapsulation: each module owns a clear responsibility, and other modules can reuse only the elements it deliberately exposes. Keeping internal actions and entities private reduces coupling, so changes stay local and consumers are protected from implementation details. A single large module tends to blur boundaries and makes reuse harder to control.

Question 2Architecture Design Fundamentals

Which ODC stage should a release pass through to be validated by QA before it reaches end users?

  1. Test Correct answer.
  2. Build
  3. Production
  4. Development

Explanation

ODC uses stage-based promotion, typically Development, Test, and Production. The Test stage is the pre-production environment where QA validates the release against realistic configurations before Production deployment. Development is for active construction, and Production serves end users.

Question 3Architecture Design Fundamentals

Which ODC asset type is designed to package reusable logic and UI patterns for consumption by multiple apps?

  1. Reactive Web App
  2. Library Correct answer.
  3. Service
  4. Mobile App

Explanation

A Library is a reusable ODC asset that exposes public elements for other apps and libraries to consume. It is not itself an end-user application, which makes it suitable for shared business rules, integrations, and UI patterns. Reactive Web Apps, Mobile Apps, and Services are app module types with their own runtime purposes.

Question 4Architecture Design Fundamentals

A shared core module contains business rules and entities used by several ODC apps. What is the best way to protect consumers from internal changes?

  1. Make every element public so consumers can reuse anything without waiting for changes.
  2. Let consumers reference the core module's internal entities and private actions directly.
  3. Expose a stable set of public elements and hide implementation details. Correct answer.
  4. Copy the core logic into each consumer app so no dependency exists between them.

Explanation

Encapsulation means the producer publishes a deliberate contract: only the public elements consumers need are exposed, while internal entities, actions, and implementation details remain private. This allows the producer to refactor internals without breaking consumers and keeps dependencies understandable. Exposing everything or copying logic undermines maintainability and reuse.

Question 5Architecture Design Fundamentals

An app in the Development stage references a library that has not yet been published to the Test stage. What must happen before the app can be deployed to Test?

  1. The app must be converted into a library before it can be deployed to Test.
  2. The referenced library must also be published to the Test stage. Correct answer.
  3. The Test stage automatically inherits every asset that exists in Development.
  4. The app can reference the Development runtime directly at run time without publishing the library.

Explanation

ODC stages are isolated deployment environments, so an app promoted to Test must have its dependencies available in that same stage. Publishing the referenced library to Test ensures the app resolves the expected producer contract there. Stages do not share a live runtime dependency path, and conversion to a library is unnecessary.

Question 6Architecture Design Fundamentals

Why should an ODC service module avoid storing per-user session state in server memory when it must scale horizontally?

  1. Because stateless services cannot expose public elements to consumer apps in other modules.
  2. Because server memory is shared across all ODC stages and therefore cannot hold tenant data.
  3. Because any instance may handle the next request, so state must be externalized. Correct answer.
  4. Because ODC service modules are not allowed to access any relational database from server actions.

Explanation

Horizontally scaled services are load-balanced across multiple instances, so a later request from the same user may reach a different instance. Per-user state kept only in one instance's memory can therefore be lost or invisible. Externalizing state to a shared store or carrying it in the request preserves correct behavior.

Question 7Architecture Design Fundamentals

In an ODC producer-consumer relationship, what does the consumer depend on?

  1. The producer's database administrator credentials and connection strings.
  2. The producer's public elements that form its contract. Correct answer.
  3. The producer's deployment pipeline configuration and stage settings.
  4. The producer's internal private actions and local variables.

Explanation

A consumer references the producer through the producer's public elements, which form the supported contract between the modules. Private actions and internal data structures are implementation details that the consumer should not depend on. This contract-based dependency keeps coupling controlled and allows the producer to evolve internally.

Question 8Architecture Design Fundamentals

Two ODC modules call server actions in each other, creating a circular dependency. Which refactoring best resolves this while preserving reuse?

  1. Merge both modules into one larger module and keep all the same internal calls and public elements.
  2. Extract shared logic into a new module that both depend on, then remove the cycle. Correct answer.
  3. Move one module's actions to client-side logic so the server-side dependency no longer exists.
  4. Make every action in both modules public so that the circular calls become valid public references.

Explanation

A circular dependency indicates that responsibilities are entangled and makes modules harder to understand, test, and reuse. The cleanest remedy is usually to extract the shared abstraction or logic into a separate module that both originals depend on, producing an acyclic dependency graph. Making everything public or moving logic to the client does not fix the underlying design problem.

Question 9Architecture Design Fundamentals

A SaaS team wants one ODC app to serve many customers while keeping each customer's data isolated. Which design is most appropriate?

  1. Rely on client-side filters so each user sees only their data.
  2. Create a separate ODC stage for every customer.
  3. Store all customer data in one entity without a tenant key and filter records by the user's name.
  4. Include a tenant identifier in tenant-owned entities and enforce tenant filtering in server-side logic. Correct answer.

Explanation

Sharing one application while isolating tenants requires tenant-aware data ownership and server-side enforcement, so every query and action is scoped to the correct tenant. Stages are deployment environments, not tenant partitions, and client-side filtering is not a security boundary. Filtering by user name alone is fragile and does not provide reliable tenant isolation.

Question 10Architecture Design Fundamentals

An ODC app calls an external payment API that can time out after the charge is accepted. Which pattern best prevents duplicate charges on retry?

  1. Retry the call immediately without any additional data.
  2. Cache the API response in the browser session only so repeated calls are avoided.
  3. Move the API call to client-side logic so that browser timeouts are shorter and retries happen faster.
  4. Send a unique idempotency key with each logical payment request and reuse it on retries. Correct answer.

Explanation

Idempotency keys let the external provider recognize that a retry represents the same logical payment, so it can return the original result instead of charging again. The key must be generated once per logical request and reused across retries. Immediate blind retries and browser-only caching do not provide a reliable duplicate-prevention guarantee.

Question 11Architecture Design Fundamentals

In an ODC architecture, which layer should own reusable business entities and business rules that multiple end-user apps consume?

  1. Foundation layer
  2. End-user layer
  3. Core layer Correct answer.
  4. Presentation layer

Explanation

The core layer holds shared business services and entities that end-user modules compose. End-user modules should contain UI and app-specific orchestration, while foundation modules wrap external systems and technical utilities. Placing shared business rules in the core layer keeps them reusable and avoids duplication across apps.

Question 12Architecture Design Fundamentals

Which ODC stage is meant to serve live customer traffic while remaining isolated from development and test activity?

  1. Production Correct answer.
  2. Test
  3. Sandbox
  4. Development

Explanation

ODC separates Development, Test, and Production stages so each has its own environment and data. Production is the stage that serves end users and should receive only validated releases. Development and Test are used for building and validating changes before promotion.

Question 13Architecture Design Fundamentals

A team needs a headless ODC module that exposes server-side logic to other apps and has no user interface. Which module type fits best?

  1. Reactive Web App
  2. Mobile App
  3. Service module Correct answer.
  4. Theme module

Explanation

A service module is designed for server-side logic and exposed actions without a UI. Reactive Web and Mobile modules are user-facing app modules. A theme module only packages styling resources.

Question 14Architecture Design Fundamentals

An end-user module needs customer data owned by a core module. Which dependency direction keeps the ODC architecture properly layered?

  1. The core module references the end-user module for data access
  2. The end-user module references a foundation module that references the core module
  3. The end-user module references the core module's public actions Correct answer.
  4. Both modules reference each other to share entities directly

Explanation

Layering should point downward: end-user modules depend on core modules, not the reverse. The core module owns its entities and exposes public actions that the end-user module calls. This keeps business rules centralized and prevents upward or circular dependencies.

Question 15Architecture Design Fundamentals

Before renaming a public server action in a widely used ODC core library, which step best identifies every affected consumer?

  1. Review the dependency and impact analysis for that public element Correct answer.
  2. Ask the library owner to rename it and fix errors after deployment
  3. Check only the Development stage because consumers exist there
  4. Delete the action and rely on runtime error messages

Explanation

ODC tracks references between producers and consumers, so impact analysis shows which modules use a public element. That visibility lets the team coordinate a backward-compatible change or update consumers before publishing. Guessing or waiting for runtime failures risks broken deployments.

Question 16Architecture Design Fundamentals

A service module exposes a public action that updates sensitive customer records. Which design best enforces authorization for every consumer?

  1. Store the caller's role in server memory for the session
  2. Check permissions inside the service action before updating Correct answer.
  3. Expose the customer entity so consumers can filter records themselves
  4. Rely on each consumer's UI to hide the update button

Explanation

Authorization belongs at the service boundary so every caller is checked consistently, regardless of which UI invokes the action. Hiding UI controls is not a security control, and exposing entities bypasses business rules. Server memory is also unsafe for role state in a scaled service.

Question 17Architecture Design Fundamentals

An ODC app must call an external system that can take several minutes to respond. Which design keeps the user experience responsive and the integration reliable?

  1. Cache the external response before the call is made
  2. Retry the synchronous call in a tight loop until it succeeds
  3. Use an asynchronous process and expose a status check Correct answer.
  4. Call the external system synchronously and increase the screen timeout

Explanation

Long-running external calls should be moved out of the interactive request path. An asynchronous process can handle the work, apply retries, and record status while the user continues. Synchronous waiting and tight retry loops consume resources and degrade the experience.

Question 18Architecture Design Fundamentals

Two core ODC modules both write directly to the same customer entity. Which change best establishes clear data ownership?

  1. Allow both modules to keep writing but add more indexes
  2. Give one core module ownership and expose controlled actions Correct answer.
  3. Move the entity into every end-user module that needs it
  4. Create a duplicate entity in each core module and sync them nightly

Explanation

Each entity should have a single owning module that enforces its rules and lifecycle. Other modules should request changes through that owner's public actions rather than writing directly. This avoids conflicting logic and inconsistent data.

Question 19Architecture Design Fundamentals

A foundation module wraps an external CRM, and many consumers call its actions directly. The CRM vendor changes its API contract. Which design change best isolates future impact?

  1. Move the CRM calls into the end-user modules for faster changes
  2. Expose the CRM entity model directly to all consumers
  3. Let each consumer call the CRM API directly so failures are localized
  4. Add an adapter contract and keep consumers on that stable interface Correct answer.

Explanation

An adapter or anti-corruption layer translates the volatile external contract into a stable internal interface. Consumers then depend on the foundation module's contract, not on vendor-specific details. When the CRM changes, only the adapter is updated.

Question 20Architecture Design Fundamentals

One ODC module exposes dozens of public actions and entities that nearly every other module calls. Which architectural problem is most significant?

  1. It has too few deployment stages
  2. It uses server actions where client variables would be faster
  3. It contains too much user-interface logic for a core module
  4. It is a tightly coupled hub with a broad public contract Correct answer.

Explanation

A module that everything depends on becomes a hub with high coupling and a broad public surface. Changes to it ripple across the system, and its internal rules are hard to protect. The usual remedy is to split it by business capability and expose narrower contracts.

Question 21Architecture Design Fundamentals

In an ODC library module, what does marking an element as Public actually allow?

  1. It allows any module that references the library to use the element in its own logic. Correct answer.
  2. It grants end users of consuming apps permission to open the element directly in a browser.
  3. It lets any module in the same stage use the element without declaring a dependency on the library.
  4. It automatically publishes the element to every stage as soon as the library is saved.

Explanation

Exposure in ODC governs visibility across a module boundary: a public element can be referenced by modules that depend on the library and are deployed in a stage where that library version exists. Marking an element public does not deploy anything, does not skip the dependency declaration, and does not grant end-user permissions, which are handled by release management and end-user roles.

Question 22Architecture Design Fundamentals

A team must deliver an app that users install on Android and iOS devices and that needs device capabilities such as the camera. Which ODC module type is intended for this?

  1. A Reactive Web App module.
  2. A Library module.
  3. A Mobile App module. Correct answer.
  4. A Service module.

Explanation

ODC module types map to a delivery target: Mobile App modules generate installable apps for mobile devices and give access to device plugins such as the camera. Reactive Web App modules target browsers, Service modules expose logic without any user interface, and Library modules only package reusable elements for other modules.

Question 23Architecture Design Fundamentals

Which ODC element executes in the server runtime, so its logic and any credentials it uses are never shipped to the browser?

  1. A screen action that updates a local variable
  2. A server action published by a service module Correct answer.
  3. A client action that calls a JavaScript library
  4. A JavaScript node inside a client action

Explanation

Server actions run inside the ODC runtime, so their logic, database access, and any secrets they hold stay on the server side. Client actions and JavaScript nodes execute in the browser or on the device, which means their code is delivered to the end user and must never contain sensitive logic.

Question 24Architecture Design Fundamentals

A consumer app calls an external address-verification API. During provider outages every request waits for the full timeout and the app's available threads are exhausted. Which design most directly fixes this?

  1. Cache the API error responses and return the cached error for all later requests.
  2. Move the call into the screen preparation so it starts earlier in the request.
  3. Wrap the call in a circuit breaker that fails fast after repeated failures and probes for recovery. Correct answer.
  4. Increase the request timeout so slow responses still have time to complete.

Explanation

A circuit breaker watches for repeated failures and then short-circuits calls instead of waiting on timeouts, which frees the threads that were being held. After a cool-down it lets a probe request through so traffic resumes when the provider recovers. Raising timeouts makes thread exhaustion worse, and caching errors indefinitely prevents recovery.

Question 25Architecture Design Fundamentals

A producer service module returns a structure that several consumer apps rely on. The team must add a new field that only some consumers need, without breaking existing consumers. Which approach fits ODC best?

  1. Rename the structure and update every consumer in the same release.
  2. Add the new attribute as optional and leave the existing attributes unchanged. Correct answer.
  3. Create a second parallel structure and delete the original one.
  4. Remove an unused field at the same time so the structure stays tidy.

Explanation

Additive, optional attributes keep the published contract backward compatible, because consumers that do not use the new attribute keep working while those that need it can start reading it. Removing or renaming attributes forces every consumer to change at once, which turns a small enhancement into a coordinated breaking release.

Question 26Architecture Design Fundamentals

A core library raises its own internal exception types for validation failures. Consumer apps should not have to know those internal types. Which design is best?

  1. Catch internal exceptions in the public action and raise a documented library exception. Correct answer.
  2. Convert every failure into one generic error message that hides all internal detail from consumers.
  3. Return a Boolean instead of raising anything and log the exception inside the library.
  4. Let internal exception types propagate so consumers can see the real cause.

Explanation

Translating failures at the public boundary keeps the library's contract stable: consumers handle one documented exception type and remain insulated from internal refactoring. Letting internal types escape couples every consumer to implementation details, while a Boolean or a single opaque message removes information that callers need to react correctly.

Question 27Architecture Design Fundamentals

One order submission traverses the UI module, an orchestration service, and a core module. Support needs to trace a single submission end to end across those modules. Which practice enables that?

  1. Recording only the final outcome in the UI module's log.
  2. Turning off module logging and asking users to describe what they saw.
  3. Logging each module's messages separately and matching them later by timestamp.
  4. Propagating a correlation ID through each call and logging it in every module. Correct answer.

Explanation

A correlation identifier travels with the request, so each module's log entries can be grouped into one trace even when many requests run concurrently. Timestamp matching breaks down under parallel traffic, and logging only the final outcome hides the module where the failure actually originated.

Question 28Architecture Design Fundamentals

A user action must trigger welcome emails, but the email provider is occasionally slow. The screen must respond immediately, and no email may be lost when the provider briefly rejects a request. Which design fits?

  1. Skip failed sends and rely on users to report that no email arrived.
  2. Trigger the email from a client action that fires after the screen closes.
  3. Record the request in a queue or outbox and process it asynchronously with retries. Correct answer.
  4. Send the email inline during the user action and raise the client timeout so it can finish.

Explanation

A durable queue or outbox decouples the user's response time from the provider's latency and keeps the request safe until it succeeds, with retries handling transient rejections. Sending inline couples the screen to the provider, and firing from the client means a closed tab loses the request entirely.

Question 29Architecture Design Fundamentals

A dashboard screen makes 30 separate fine-grained server action calls to one core service module to assemble a single summary, and most of the response time is network round trips. Which refactor is best?

  1. Add a coarse-grained composite action in the core module that returns the summary in one call. Correct answer.
  2. Move all 30 calls into a client action so that the browser can issue them in parallel to reduce latency.
  3. Cache all 30 responses indefinitely in the UI module so repeat visits are fast.
  4. Copy the relevant core module logic into the UI module so the network hops disappear.

Explanation

When round trips dominate, consolidating the work into one composite server action removes 29 network hops and lets the service batch its data access in a single place. Parallelizing the same calls in the browser multiplies load on the service and keeps per-call overhead, and duplicating logic in the UI module destroys the ownership boundary the architecture depends on.

Question 30Architecture Design Fundamentals

A checkout workflow reserves inventory through one ODC service module and charges a card through a second. The two modules cannot share one database transaction. Which design is most appropriate?

  1. Wrap both calls in one transaction by letting the second module write to the first's entities.
  2. Use a saga with compensating actions that undo completed steps when a later step fails. Correct answer.
  3. Charge the card first and quietly discard inventory reservation failures.
  4. Retry the failing step indefinitely until both steps eventually succeed.

Explanation

When a single atomic transaction cannot span two owners, a saga accepts eventual consistency and makes recovery explicit: each successful step has a defined compensation that runs if a later step fails. Sharing one transaction across module boundaries violates data ownership, while unbounded retries and silent drops both leave the business in an inconsistent state.

Question 31Architecture Design Fundamentals

A team is building an ODC application and needs a container for reusable server actions, structures, and entities that several modules will consume, but the container itself will not be deployed as an end-user interface. Which ODC module type fits this need?

  1. A mobile app module
  2. A library module Correct answer.
  3. A web app module
  4. A production stage

Explanation

ODC library modules package reusable elements such as server actions, structures, and entities for other modules, and they do not provide an end-user interface. Web app and mobile app modules are intended for user-facing screens, while a stage is a deployment environment rather than a code container.

Question 32Architecture Design Fundamentals

In ODC architecture, which construct groups related modules so they can be managed and deployed together through the development lifecycle?

  1. A REST integration
  2. An application Correct answer.
  3. A stage
  4. A public element

Explanation

An ODC application is the lifecycle container that groups related modules, while stages are the environments within that lifecycle. Public elements are exposed module members, and REST integrations are connections to external systems, not grouping units.

Question 33Architecture Design Fundamentals

A release candidate has passed development checks and now needs business acceptance testing before it is promoted to live customer use. Which ODC stage is intended for that acceptance testing?

  1. Development
  2. Build
  3. Test Correct answer.
  4. Production

Explanation

ODC separates Development, Test, and Production stages, and the Test stage is the non-production environment for validation and acceptance before Production. Development is for active building, Production serves live users, and Build is not an ODC stage.

Question 34Architecture Design Fundamentals

A core ODC module owns a Customer entity with sensitive fields. A reporting module needs only customer name and region. Which public interface best limits coupling and data exposure?

  1. Have the reporting module call an internal private action in the core module through a shared session.
  2. Copy the Customer entity into the reporting module and refresh it with a timer.
  3. Expose a server action that returns a structure containing only name and region. Correct answer.
  4. Publish the entire Customer entity as a public entity and let the reporting module select only the fields it needs.

Explanation

A purpose-built server action returning a minimal structure gives the reporting module only the fields it needs while keeping sensitive fields and schema details inside the owning module. Public entities and copied entities widen or duplicate the contract, increasing exposure and maintenance risk. A private action is not an accessible cross-module interface.

Question 35Architecture Design Fundamentals

A reference-data service module changes its data only a few times per day, but a high-traffic web app reads the same list on every screen load. Which design best reduces load without sacrificing correctness?

  1. Copy the reference data into each user's browser local storage permanently.
  2. Cache the list in the web app indefinitely and never refresh it after changes.
  3. Cache with a short TTL and refresh after the update action. Correct answer.
  4. Call the service module on every screen load and rely on the database cache.

Explanation

A short time-to-live bounds staleness, and refreshing after the service action that changes the data keeps the cache aligned with the source of truth. Indefinite or permanent caches become stale, while calling on every screen load does not reduce the repeated work.

Question 36Architecture Design Fundamentals

Module A calls a public action in Module B, and Module B needs a value that only Module A can supply. The team is tempted to add a reference from B back to A. Which design avoids a circular dependency in ODC?

  1. Duplicate Module A's logic inside Module B and remove the original.
  2. Make Module A's private action public so Module B can call it without a reference.
  3. Move the shared contract into a lower-level library that both modules reference. Correct answer.
  4. Add the back-reference because ODC resolves circular module references at build time.

Explanation

A shared lower-level library inverts the dependency so both modules depend on a stable contract instead of on each other, which removes the cycle. ODC does not rely on circular module references as a design technique, and making an action public does not eliminate the reference or the coupling. Duplicating logic creates drift and ownership problems.

Question 37Architecture Design Fundamentals

An ODC module contains customer registration screens, invoice PDF generation, and a nightly import of supplier prices. Which architectural concern does this most clearly indicate?

  1. Low cohesion because unrelated responsibilities are grouped in one module. Correct answer.
  2. Low coupling because the module has no public elements.
  3. High scalability because the module has fewer dependencies.
  4. High cohesion because all responsibilities support the same application.

Explanation

The module mixes customer-facing UI, document generation, and supplier data import, so it has no single focused reason to change; that is low cohesion. Cohesion measures how strongly related a module's responsibilities are, not whether they belong to the same application. Fewer dependencies do not compensate for unrelated responsibilities.

Question 38Architecture Design Fundamentals

A service module exposes a public action that returns all orders for a customer, and some customers have tens of thousands of orders. Which interface change best protects response time and memory for consumers?

  1. Return the full result set but ask consumers to loop over it faster.
  2. Increase the server timeout so the full response can complete.
  3. Remove the action and let each consumer read the Orders entity directly.
  4. Add optional paging inputs and return one page plus total count. Correct answer.

Explanation

Pagination bounds the work and payload of each call, allowing consumers to retrieve large result sets incrementally without exhausting memory or timeouts. Returning everything faster or increasing timeouts does not remove the underlying scaling problem. Direct entity access couples consumers to the schema and bypasses the service contract.

Question 39Architecture Design Fundamentals

A widely consumed ODC library has a public server action GetCustomer( CustomerId ). The team adds a new required input IncludeInactive to that action. What is the architectural impact?

  1. It has no impact as long as the action's output structure is unchanged.
  2. It is backward compatible because ODC supplies a default for every new input.
  3. It is breaking because existing callers do not supply the new required input. Correct answer.
  4. It only affects callers that use the action from mobile apps.

Explanation

Adding a required input changes the action's contract, so every existing caller must be updated; that makes the change breaking. Backward-compatible evolution normally uses optional inputs with safe defaults or a new action version. Compatibility is not limited to the output structure or to mobile callers.

Question 40Architecture Design Fundamentals

A public ODC service action charges a customer's card. If the caller times out and retries, the customer must not be charged twice. Which design addresses this requirement?

  1. Accept an idempotency key and return the stored charge result on retries. Correct answer.
  2. Require the caller to retry only during off-peak hours.
  3. Log each request and manually refund duplicates after the fact.
  4. Increase the action timeout so the first request always completes before a retry.

Explanation

An idempotency key lets the service recognize a retried request and return the stored result instead of charging again, which makes a non-idempotent operation safe to retry. Timeouts and off-peak retry rules do not prevent duplicate requests, and manual refunds are a reactive control rather than a design safeguard.

Question 41Application Architecture and Decomposition

What is the main architectural benefit of decomposing an ODC application into smaller modules?

  1. Each module exposes more public elements.
  2. Integration testing is no longer needed.
  3. Higher cohesion and lower coupling. Correct answer.
  4. Fewer deployment environments are required.

Explanation

Decomposition groups related responsibilities into cohesive modules and minimizes dependencies between those modules. This makes the application easier to understand, change, and test, while keeping module contracts small. It does not change environment counts, require a larger public surface, or remove integration testing.

Question 42Application Architecture and Decomposition

In ODC, which mechanism allows a library module to expose reusable actions to consuming apps while keeping other elements hidden?

  1. Private elements
  2. Public elements Correct answer.
  3. Screen widgets
  4. Local variables

Explanation

Libraries expose only the chosen actions, structures, and entities as public elements; all remaining elements stay private and cannot be referenced by consumers. This encapsulation creates a stable contract and limits the impact of internal changes.

Question 43Application Architecture and Decomposition

A shared audit-logging action is needed by several ODC apps. Where should the team place it to avoid duplication?

  1. In each app's main UI module
  2. Inside a screen action of the first app
  3. In a shared library module Correct answer.
  4. In a local variable of each app

Explanation

Cross-app reusable logic belongs in a library module so it is defined once and maintained centrally for every consumer. UI modules and screen actions are presentation-specific, and local variables cannot store reusable logic.

Question 44Application Architecture and Decomposition

An ODC module combines customer data persistence logic with customer-facing screen logic. Which decomposition principle is most directly violated?

  1. Lazy loading of large UI data sets
  2. Responsive design across all device form factors
  3. Single sign-on for all internal users
  4. Separation of concerns Correct answer.

Explanation

Separation of concerns requires distinct responsibilities such as persistence and presentation to be organized into separate modules or layers. Mixing them lowers cohesion and makes changes to one concern riskier for the other.

Question 45Application Architecture and Decomposition

Two ODC modules reference each other's public elements, creating a circular dependency. Which refactoring best resolves this?

  1. Merge both modules into one larger combined module.
  2. Duplicate the shared logic in both of the modules.
  3. Move shared logic to a common lower module. Correct answer.
  4. Make every element public in both modules.

Explanation

A circular dependency is removed by inverting the direction of the shared dependency: common logic moves to a lower-level module that both original modules can reference. This keeps the dependency graph acyclic and preserves reuse.

Question 46Application Architecture and Decomposition

When decomposing an ODC app into layers, which layer should hold reusable business rules that are independent of any user interface?

  1. The end-user layer
  2. The core layer Correct answer.
  3. The orchestration layer
  4. The theme layer

Explanation

The core layer contains business entities and rules that are independent of presentation, so multiple UI or service modules can reuse them. End-user and theme layers deal with presentation, while orchestration coordinates process flow.

Question 47Application Architecture and Decomposition

A library module exposes dozens of public elements, but consuming apps use only two. What is the main architectural risk?

  1. Guaranteed performance gains from public exposure
  2. Wider coupling and maintenance contract Correct answer.
  3. Automatic reduction of module dependencies
  4. Improved encapsulation because more elements are visible

Explanation

Every public element becomes part of the module's contract, so exposing unused elements widens coupling and increases the impact of future changes. A minimal public surface better preserves encapsulation.

Question 48Application Architecture and Decomposition

In domain-driven decomposition of an ODC application, what does a bounded context define?

  1. A boundary for a consistent domain model Correct answer.
  2. A UI theme shared by all apps
  3. A single module holding every enterprise entity
  4. A deployment environment for testing

Explanation

A bounded context is the explicit boundary within which a domain model and its terms have a consistent meaning. Different contexts may use similar words differently and translate at their edges, which guides module boundaries.

Question 49Application Architecture and Decomposition

A team decomposes an ODC app strictly along its current organizational structure. Which risk does Conway's law highlight?

  1. The app will automatically achieve high cohesion
  2. The decomposition will eliminate cross-team dependencies
  3. Architecture mirrors team silos and adds coupling Correct answer.
  4. The architecture will always match the business domain

Explanation

Conway's law observes that system design tends to copy the communication structures of the organization that builds it. Decomposing only by team chart can therefore produce boundaries that do not match business capabilities and add coordination coupling.

Question 50Application Architecture and Decomposition

When should an ODC team separate a service module from a UI module?

  1. When the team prefers JavaScript over C#
  2. When the UI needs more screens than the current module contains
  3. When the database has fewer than ten entities
  4. When the same logic must serve multiple channels or apps Correct answer.

Explanation

A service module is justified when business logic must be reused across channels or applications, giving consumers a stable contract independent of presentation. Screen count, database size, and language preference are not decomposition drivers.