Evolution of JD Family Account Architecture: From Classic Three‑Tier to Domain‑Driven PaaS

As JD's retail business continues to grow, the Family Account product faces increasing challenges such as communication overhead, delivery efficiency, asset consolidation, unified governance, and rapid innovation, prompting a need to share a core business system with external commercial customers, support cloud‑native integration, and enable low‑code ecosystems.

The Family Account leverages household relationships as a marketing foundation, expanding to multi‑family scenarios and providing eight key benefits (e.g., family chat, shared lists, affection payment, logistics sharing, exclusive pricing and coupons), thereby enhancing user experience and supporting various business units through precise and emotional marketing.

Initially built on a classic three‑tier architecture (controller → service → DAO), the system quickly became cumbersome as business complexity, traffic, and co‑development demands grew, leading to scalability, maintainability, and performance issues.

The first upgrade refactored the monolithic layers, introduced service‑oriented decomposition using technologies like JSF, and isolated core services for external consumption, improving modularity, traffic isolation, and deployment separation.

The second upgrade focused on external empowerment and extensibility, adopting domain‑driven design (DDD), the "Cangjingge" collaborative platform, and a PaaS approach to reuse core capabilities, standardize interfaces, and enable plug‑in extension points.

Guided by DDD, Hexagonal, Onion, and Clean Architecture principles, the new layered model separates infrastructure, application services, and domain layers, ensuring high cohesion, low coupling, independent deployment, and testability.

The resulting PaaS architecture is built with Maven multi‑module Java projects, using parent‑child POMs, and provides a unified core for relationship management that can be consumed by other business units and external tenants.

The architecture now supports SaaS‑style multi‑tenant scenarios, enabling the Family Account to serve as a relationship‑as‑a‑service platform, with potential extensions to friend, classmate, or other intimate relationship models, and lays groundwork for low‑code visual development.

Overall, the transformation demonstrates significant gains in code‑architecture alignment, extensibility, and decoupling, while providing a reusable core for other teams and paving the way for future research into low‑code platforms and further cloud‑native commercialization.