The assertion model identifies assertions. When a software build is planned, a subset of the assertions can be included in an AM Implementation. Most assertions will be implemented as software components. Assertionizer software supports Implementation Design; the process of identifying how the assertions will be implemented. This provides a close coupling between the model and the proposed software. And it assists the implementation designer to identify some of the domains and bounded contexts that frame the solution.
Event Sourcing and Command Query Separation(CQS)
Event sourcing is a design pattern where changes in the information in a system are captured as a series events, rather than storing just the current state.
Command Query Separation (CQS) recognizes that a information about current state can be retrieved with a query or changed with a command. Assertion modeling supports this. The decision of an assertion may initiate a command to persist a set of information about a context. And it may retrieve persistent information about a context. Both these are separate decisions, separate assertions. One decision takes a proposed new state and persists it. The other takes a context and returns its current persisted state.
This concept is important in how AM supports DDD. A single DDD Entity implements both these decisions. But in the AM the assertion may deliver information outside its bounded context.
Decisions in another Domain may require a state from a related Domain.
But within a Domain, or a bounded context residing within it, the meaning of that information is prescribed by the authority. The persistent store delivers the current state of affairs defined by the Authority because it is under their authority. When an external authority retrieves, they retrieve information as defined by the source. Then they make a separate business decision to reinterpret, or redesign or repurpose that information.
Information Responsibility and the Bounded Context
DDD puts strong emphasis on Ubiquitous Language. A ‘ context space’ in the code where the meaning is consistent. Meaning might change when you cross a boundary, but definitions are consistent within. In spite of years of ‘Information Management’, the business community has struggled with this. Perhaps in ‘Content Management’ they talk about ‘Taxonomy’ but methods to define it are ad-hoc.
But in assertion modeling the meaning is defined in the Frame by the Authority. All the information guided by an ‘authority’ should be consistent. And if the authorities report upwards some consistency between sub authorities should be consistent, or at least have defined meanings.
It is in this ‘business authority context’ that the bounded context arises. Ambiguous, vague, or shaky meaning in the business can only be passed to implementation to propagate.
What this means is that the Authorities in the assertion model suggest the bounded contexts in DDD implementations. When information passes between business functions it probably passes between bounded contexts. And domains(and business functions) roll this up further.
Communications in the business tends cluster within functions. In a well defined business, communication between functions should be minimized and clear, just like between domains.
“The structure of any system tends to mirror the communication structure of the organization that designs it.” — Melvin E. Conway
So for establishing software architecture components, the assertion model provides the ‘landscape’. A well designed organization will have parts of the assertion model where connections are concentrated, and between these sections (‘bounded functions’?) the communications should be minimized. When performing the implementation design look for these ‘natural sparse boundaries’ even if reporting lines may suggest otherwise.
Conscientious developers struggle to reverse engineer separation of concerns from a business that has implemented them organically.