Architecture Overview
A deal is an instance of a deal type. Every deal instance can be one and only one type.
DANGER
What about overall deals?
Deal types are defined through deal models.. Deal models are not solely data models, such as might be described in an entity-relationship diagram. We'll discuss deal modeling in further detail below.
Deal types are implemented as programs, because deals cannot be adequately described in data models alone. Since deals have their own business rules, initialization logic, and calculations, they must be described both as data models and as computation. It is therefore best to think of each deal type as a small program ("deal program") that can be executed by the deal engine.
Deal data is exposed from the deal program via standardized interfaces, reached as API endpoints. Calling programs look at the deal program's interfaces rather than referencing a single canonical schema. Each deal program owns its own schema and data model which remains largely hidden from calling programs.
Deal programs ("deal types") are versioned and registered in a deal registry. Calling programs find the deal types in the registry.
The process of designing a deal model
Domain Boundaries
There are also important principles describing what the Deal Engine must not do:
While the deal engine may consume data from the Authoritative Data system, the deal engine should not “know”, or depend on the data from any other system.
The deal engine shall provide only the services described by the interfaces described in this documentation, and no other services.
The deal engine must not take on responsibility for business processes that should be provided by downstream systems, such as revenue recognition or commission structure management.