05 · Architecture · Modules and consistency
Warehouse, finance, and a spreadsheet must not each keep their own stock
The senior architect decides module boundaries and whose copy wins when something fails. Senior means the right to send back “write it temporarily for now.” Cross-system identity is not this role; that goes to the solution architect.
The senior architect splits ownership, not jargon
The solution consultant has already set system-level boundaries as keep, build, read, and write. The senior architect turns that into modules: inventory, documents, master data, privilege, integration, printing—what data each owns, and how other modules may call it. The job is allergic to “write it temporarily for now.” A temporary write becomes a second set of books. Before development starts, this must be written down: only the inventory module changes stock quantities; the document module may only submit an intent; master data is read-only; the integration module must not change stock directly, it may only publish a confirmed business event.
He also specifies consistency, instead of making every call synchronous. Sync looks simple. When Kingdee times out, the receiving page spins, and the warehouse clerk taps again. In the architecture, receiving finishes locally to “pending write-back,” and integration retries from the event. That is not an optional implementation detail. It is a module boundary. Anyone who puts write-back inside the receiving transaction has imported an external failure into warehouse work.
Failures an architecture note must answer
DaXi Technology requires an architecture note to answer five failures, not only to draw arrows for the happy path. Does a duplicate submit post twice. What is the local state after an external timeout. If master data is missing, is it rejected or created. When two modules change the same stock at once, who wins. When a message is delivered twice, how does the downstream side recognize it. A module that cannot answer does not start. Stack choices, such as a queue versus a scheduled pull, come after those answers. If the choice comes first, the team will change what a business failure means in order to use a component.
The senior architect does not write the field table for every API. That is the backend and integration engineers' work. He reviews whether a field table has crossed a boundary—for example, a stock balance sent from the frontend being overwritten directly. A design that crosses is sent back, even if it makes the demo faster. Shared module conventions across projects are also closed by this role, so each project does not invent another way to write stock.
The time WMS, ERP, and Excel all changed stock
On a distribution project, the warehouse received in the new system, finance read stock in Kingdee, and planners still used Excel for sellable quantity. The three sides did not match every night. The senior architect did not accept “build a reconciliation report” as the fix. A reconciliation report only displays three sets of books together. He specified: the owner of sellable stock is the inventory module in the new system; Kingdee receives a summary of closed documents and does not write warehouse quantities back; Excel loses the right to enter numbers and exports from the inventory module instead, with time and warehouse on the file, and must not be imported back. If a planner finds a wrong number, they raise a variance document. They do not edit the sheet.
In the implementation, receiving, putaway, and closing a variance are all commands of the inventory module. Integration only consumes the “document closed” event. Implementation removed the Excel macros from planners' machines. After go-live, Kingdee's numbers were still four hours late one day because the queue jammed, but warehouse sellable stock was not overwritten by a Kingdee write-back. That is the direction architecture must keep: late is allowed; reverse overwrite is not.
Module boundaries are handed to the Tech lead to enforce in code review. Cross-system identity and accounts are not solved on this page. They go to the Solution architect.
The architecture note must also write the read model. A list page may denormalize status to make queries fast, but that copy may only be updated by events. The list must not become a second set of books that can be edited. A design that lets someone change a quantity on the pending-receiving list and save it is sent back. Queries may be fast. Commands must go through the inventory module. If speed is bought by giving up a single writer, the reconciliation cost is paid in one go at month-end.
He reviews architecture against a real failed document, not only a box diagram. On that document, every hop must point to a module, and it must be clear which hop may retry. An arrow that cannot be pointed to is deleted from the note. If deleting it breaks the business path, the modules are not split yet. Keep splitting. Do not write code first.