Distribution Boundary Designer

Example 1 — Reject Distribution for a Two-Team LOB App

Scenario: A 12-person engineering team across two squads is building an internal CRM. Engineering lead proposes microservices "for clean boundaries between the sales squad (contacts, deals) and the support squad (tickets, SLAs)."

Trigger: "Should we use microservices for our two-squad CRM?"

Process: 1. Apply First Law Filter: - Client-server divide: Yes (browser client + server). But this is the standard web-app boundary, not an argument for internal microservices. - Independent scaling: No — contacts/deals and tickets/SLAs have similar load profiles. - Different security zones: No. - Vendor package: No. - Independent deployment: "Nice to have" but not operationally required. - Result: No legitimate reason for internal service distribution. 2. Recommend modular monolith: define a contacts-deals package and a tickets-slas package with explicit module boundaries, shared domain types, and clear internal APIs. Each squad owns their package. 3. Note: the existing web-app boundary (browser ↔ app server) is the natural Remote Facade. A single CRMService facade handles screen-level operations for both squads. 4. Anti-pattern audit: distribution-by-class risk = not applicable (not distributing). Domain logic in facade = not applicable.

Output: Distribution Design Record stating "Do not distribute internally." Modular monolith with squad-owned packages. One Remote Facade for the browser-server boundary.

Example 2 — Extract Payments as a Distributed Boundary

Scenario: E-commerce platform. Payments team requires PCI-DSS compliance in an isolated network zone. The search subsystem handles 50x the load of the product catalog at peak.

Trigger: "We need to separate payments for PCI compliance and search for scaling. How do we design those boundaries?"

Process: 1. Apply First Law Filter: - Security zone (PCI): Yes — payments must live in an isolated environment. Legitimate. - Independent scaling (search): Yes — 50x load differential is a real scaling reason. - All other subsystems: No legitimate reason. 2. Two boundaries identified: Catalog ↔ Payments, Catalog ↔ Search. Everything else (orders, inventory, user) stays in the monolith. 3. Design Payments Remote Facade (PaymentService): - AuthorizePayment(orderId, paymentMethodDTO) → PaymentResultDTO - CapturePayment(authorizationId) → CaptureResultDTO - RefundPayment(paymentId, amount) → RefundResultDTO - NOT: GetCard(), UpdateCard(), GetAuthorization() — these are fine-grained domain calls 4. Design DTOs: PaymentMethodDTO (cardToken, billingAddress, amount), PaymentResultDTO (authorizationId, status, errorCode). Assembled from domain card/billing objects. Not coupled to domain class structure. 5. Design Search Remote Facade (SearchService): - SearchProducts(query, filters, pagination) → ProductSearchResultDTO - SuggestProducts(partialQuery) → SuggestionDTO[] 6. Interface style: Payments = gRPC (internal, same platform, high reliability needed). Search = REST/JSON (browser clients query search directly; must be cross-platform). 7. Anti-pattern audit: no distribution-by-class, facades are thin, DTOs are use-case-shaped.

Output: Distribution Design Record with two boundaries (PCI, scaling), facade specs, DTO specs, interface styles.

Example 3 — Fix Legacy Chatty Distributed Objects

Scenario: Legacy J2EE system from 2005. Every entity bean (Customer, Order, OrderLine, Product, Address) is a separate remote EJB. Displaying an order summary screen makes 15-20 remote calls. Performance is unacceptable.

Trigger: "Our EJB app is painfully slow. Each screen makes dozens of remote calls. How do we fix this?"

Process: 1. First Law Filter: Application server is separate from DB (legitimate). The internal EJB-to-EJB calls are the problem — distribution by class applied to the domain model. 2. Diagnosis: Classic distribution-by-class anti-pattern. The EJBs mirror the domain class structure. Every property getter is a remote call. 3. Remediation: - Keep domain objects as plain in-process Java objects (POJOs) — remove remote interfaces from Customer, Order, OrderLine, Product. - Introduce a single OrderService Remote Facade with use-case methods: GetOrderSummary(orderId) → OrderSummaryDTO, UpdateOrderStatus(orderId, statusDTO). - OrderSummaryDTO aggregates order header + customer name + line items + product names in one call. - Assembler populates the DTO from the fine-grained domain objects. 4. Interface style: Keep as EJB session bean Remote Facade (same platform) or migrate to gRPC for modern replacement. 5. Expected result: 15-20 calls → 1-2 calls per screen interaction.

Output: Refactoring plan with identified chatty calls, new facade spec, DTO design, migration sequence.