A Methodology for Translating Business Models into Data Models: Community Group Buying Case Study

From a developer's perspective, technology should empower business, and developers can enhance their technical skills through thoughtful business model design. This article introduces a methodology for abstracting business models into data models, aiming to reduce redesign risk when business requirements evolve.

Background : Developers often participate in PRD reviews and then dive into database table design. While familiar domains are straightforward, unfamiliar domains require systematic analysis to ensure the resulting tables are usable, extensible, and aligned with business needs.

Key Insight : A good methodology guides independent analysis and problem‑solving when facing new business scenarios.

Terminology :

Domain: High‑level business area (e.g., e‑commerce, logistics).

Sub‑domain: Specific parts of a domain (e.g., orders, payments).

Modeling: Mapping and abstraction of a domain.

Thought Process :

Object‑oriented analysis provides a design mindset for translating business concepts into data structures.

Figure 1: User‑to‑Developer Thinking Diagram

Methodology :

Identify objects (e.g., OFC system, group order, product, scheduling line).

Organize objects, resolve ambiguities, and consolidate duplicates.

Define relationships between objects (one‑to‑one, one‑to‑many, many‑to‑many).

Enrich model details: attributes, states, boundaries.

Map domain objects to data models, considering derivations, redundancy, and extension tables.

Case Study: Community Group Buying – Pre‑Scheduling Model

(1) PRD Requirement Description: The pre‑scheduling system receives daily group order data from the OFC system, including created, updated, and cancelled orders.

(2) Identify Objects: OFC system, group order (production order), product, quantity, address, leader info, scheduling line, etc.

(3) Organize Objects: Consolidate overlapping terms, decide when to elevate a term to a separate object (e.g., employee, store).

(4) Define Relationships: One group order can have many products; one scheduling line can contain many group orders.

(5) Refine Model Details: Add sub‑domains, attributes, states, and boundaries.

(6) Map to Data Model: Derive attributes (e.g., transport task code), handle low‑level and high‑level redundancy, and consider vertical splitting into extension tables.

Figure 3: Object Model (simulated fields)

Figure 4: Final Data Model Diagram

Extended Thoughts :

Domain model design considerations (objects, functions, interfaces).

Methodology: verb + object ↔ method + object to separate business operations from entities.

Microservice boundaries and interface exposure.

Figure 5: Domain Model Call Relationship Diagram

Conclusion : A solid methodology equips you to independently analyze and solve problems in unfamiliar business domains, ensuring that the resulting data models are maintainable, extensible, and aligned with evolving requirements.