Questions & explanations
1. You have a classification tree with classifications A (classes a1,a2), B (b1,b2,b3), and C (c1,c2). How many test cases would you get if you want each class to appear at least once?
The minimum number of test cases is the size of the largest classification, which is B with 3 classes. You need at least 3 test cases so that each class of B appears once. But you also need to cover all classes of A and C. You can design 3 test cases that include each class of A (2) and C (2) at least once, but careful: with only 3 tests, some classes of A or C might be missing. Actually, to cover all classes of all classifications at least once, you need a number equal to the maximum class count, and you can arrange the other classes to fit. For example: test1: a1,b1,c1; test2: a2,b2,c2; test3: a1,b3,c1? That covers all classes? a2 appears once, c2 appears once, but a1 appears twice, c1 appears twice. So yes, 3 tests cover all classes. This is the 'each choice' coverage criterion.
2. How does serverless architecture differ from traditional server-based applications?
In traditional applications, you manage servers yourself – you choose the hardware, install software, and handle scaling. Serverless architecture removes that responsibility; the cloud provider runs your code on demand. With serverless, you don't pay for idle capacity; you only pay for actual usage, like the number of function invocations and execution time. Scaling is automatic: the provider adds more instances when load increases. Traditional apps require careful capacity planning and manual scaling. Serverless functions are stateless and short-lived, while traditional apps can keep persistent connections. However, serverless has limits like cold starts (delay when a function hasn't been used) and maximum execution time. It's best for variable or low-traffic workloads.
3. Give an example of how SOA is used in a real business scenario.
A large online retailer uses SOA to manage orders, payments, inventory, and shipping. Each business function is a separate service. When a customer places an order, the ordering service sends a message to the payment service to charge the credit card. Then it asks the inventory service to reserve items. Finally, it calls the shipping service to arrange delivery. If the retailer adds a new sales channel like a mobile app, it can reuse all those existing services. The enterprise service bus coordinates the messages between services. This way, the company avoids building duplicate logic and can change one service, like switching payment providers, without touching others. It also helps the retailer expand globally by adding services for different currencies.
4. How does serverless compare with Platform-as-a-Service (PaaS)?
PaaS lets you deploy applications without managing the underlying servers, but you still need to define the application's runtime environment and scaling rules. There is always at least one instance running, so you pay for idle time. Serverless, especially FaaS, goes further: code runs only when triggered, and you pay per execution. PaaS is better for long-running applications like web APIs with persistent connections, while serverless suits event-driven, bursty workloads. PaaS typically has no cold start, but can be more costly for low traffic. Serverless scales to zero automatically; PaaS requires manual scaling configuration or auto-scaling. Both reduce operational overhead, but serverless offers finer granularity and cost savings for sporadic usage.
5. How does SOA compare with microservices architecture?
SOA and microservices both use services, but they differ in size and scope. SOA services are often larger and run on a shared platform like an enterprise service bus. Microservices are smaller, independent, and each has its own database and deployment. SOA typically shares data models across services, while microservices enforce loose coupling through separate data stores. Microservices are easier to scale because you can scale only the busy service, but they require more operational effort. SOA is better for integrating existing large systems, whereas microservices suit new, cloud-native applications. Both promote reusability, but microservices aim for faster independent updates. Choosing between them depends on the organization's size and needs.
6. How does hexagonal architecture compare with traditional layered architecture?
Traditional layered architecture has layers like presentation, business, and data access, with each layer depending on the layer below. Dependencies flow top-down, so business logic often depends on the database. Hexagonal architecture flips this: the core business logic depends only on ports (interfaces), and adapters (implementations) depend on the core. This inverts the dependency, making the core independent of external systems. In layered architecture, changing a database can affect business logic, while in hexagonal, you just add a new adapter. Hexagonal also allows multiple adapters for the same port, like both a REST API and a CLI user interface. Layered architecture is simpler for small apps, but hexagonal suits large, evolving systems.
7. What are the layers in Clean Architecture and what do they contain?
Clean Architecture typically has four layers. The innermost is 'Entities' – enterprise-wide business objects like a Customer or Order. Next is 'Use Cases' (or interactors) that contain application-specific business rules, like 'PlaceOrder'. Then comes 'Interface Adapters' which convert data between use cases and external formats, like controllers and presenters. The outermost layer is 'Frameworks and Drivers' including the web framework, database, and UI. Dependencies point inward: use cases depend on entities, adapters depend on use cases, and frameworks depend on adapters. Each layer communicates through interfaces defined by the inner layer. This separation allows you to change the web framework or database without touching business logic.
8. What is Function-as-a-Service (FaaS) in serverless architecture?
Function-as-a-Service (FaaS) is a cloud computing model where you write small pieces of code (functions) that run in response to events. You upload your code to a cloud provider, and the provider automatically runs it when triggered, like when a file is uploaded or an HTTP request comes. You don't manage servers – the provider handles scaling and infrastructure. Each function runs for a short time and you pay only for the execution time and resources used. FaaS is a key part of serverless architecture, allowing you to build applications without worrying about servers. Examples include AWS Lambda, Google Cloud Functions, and Azure Functions. FaaS is great for event-driven tasks like image processing or data transformation.
9. How does Clean Architecture compare with hexagonal architecture?
Clean Architecture and hexagonal architecture share the same idea: isolate the core from external concerns using interfaces. Both invert dependencies and put business logic at the center. Hexagonal architecture focuses on ports and adapters, while Clean Architecture defines more layers (entities, use cases, interface adapters, frameworks). The dependency rule is common to both. Clean Architecture is more prescriptive about layer naming and how data flows through the system. Hexagonal architecture is simpler and often used for smaller applications. Both achieve high testability and maintainability. The choice between them depends on the project's complexity and team preferences. Many practitioners combine ideas from both.
10. Give an example of a domain model for an online store using DDD concepts.
In an online store, the domain model has a 'Customer' entity with attributes like name and order history. 'Product' could be an entity or value object, but often it's an entity with a SKU. The 'Order' is an aggregate root containing 'OrderLine' value objects, each referencing a product and quantity. A 'Payment' value object holds amount and method. Domain events like 'OrderSubmitted' trigger 'InventoryReserved' and 'EmailSent'. The 'Catalog' bounded context handles product search, while 'Ordering' handles purchases. Each bounded context has its own model: in Catalog, 'Product' has price and description; in Shipping, it's a package with weight. This separation keeps each part clean and aligned with its business purpose.
11. What are the limitations of serverless architecture?
Serverless has several limitations. One is cold start: when a function hasn't been called for a while, the provider needs to load it, causing a delay of seconds. This can be bad for user-facing apps that need fast responses. Another is timeout limits – most providers cap function execution time (e.g., 15 minutes on AWS Lambda). Long-running tasks like batch processing may not fit. Serverless functions are also stateless, meaning you cannot store data locally; you must use external services like databases or caches. Debugging and monitoring can be harder because functions are ephemeral. Vendor lock-in is a risk – code written for one provider may not work on another. Cost can also be unpredictable for high-traffic apps.
12. How does DDD compare with a traditional data-driven design approach?
Traditional data-driven design starts with the database schema and builds code around it, focusing on tables and relations. DDD starts with the business domain and models it in code, prioritizing behavior over data storage. In DDD, the model drives the database design, not the other way around. Traditional design often leads to anemic domain models with getters and setters, while DDD produces rich models with business logic. DDD uses patterns like aggregates to enforce invariants, whereas data-driven design might rely on the database for rules. DDD requires close collaboration with domain experts, while data-driven design often works from fixed requirements. DDD is better for complex domains that change frequently.