Implementation Design With AM
Domain
An business is a network of decisions and connections. AM captures this network. Subdividing this network can be done from a number of perspectives. When undertaking this subdivision for the purposes of DDD the objective is to minimize and simplify the interactions between domains in order to keep changes from affecting other software components.
If we assume that business changes that may affect software components have a tendency to align within business responsibilities.
Some operational information may need to flow between corporate divisions. The story of the amount of business handled by sales but generated by a marketing initiative may require operational sales information to be analysed to support marketing. Or marketing may wish to initiate contact with high volume purchasers. This is a prime example of information passing between divisions. But it is important to remember that this is probably one way information. Marketing is unlikely to have regular decisions that update information in sales.
It is also rare that changes that are reflected in code cross domain boundaries. Perhaps subdomains, but much more across bounded contexts.
Bounded contexts are much more of a coding concept where naming within software components becomes more of an issue. Here the Ubiqutous Language refers to Code. Within an organization there is often cases where terms are not consistent across organizational boundaries.
But decisions must be made, when software development begins, to define the structure or architecture of the components, their racking, and their interdependencies.
And the challenge comes when the business structure begins to deviate from the software structure.
The whole foundation of DDD is to align these. ‘If the code is structured like the business then a small business change should be small in the code.
DTOs
These may be java records or JSON. The are defined data stuructures and the information within them. They don’t have behavior (like SW components or functions).
There may be invariants that are implied by the schema or by business rules.
In AM the Frame defines the structure of a DTO. The assertion itself is responsible for enforcing invariants that ensure the meaning of the DTO frame is conserved.
Assistance within a cubicle( an implemented assertion) will assist an Authority in populating the DTO according to the meaning. So invariants are part of the frame. And are specified business rules applied to decisions. Business will produce assertions that do not have constraints, perhaps as a pure text that is not parsed for more specific meaning.
Invariants
When information created by assertions in a frame is transferred to a DTO (which is a connection concept) is to be persisted it may be received by a SW component that validates it. That validation may fail where the originator assertion passed the invariants. This is a case where meaning responsibility changes. In AM, when a connection is defined into an assertion it is the receiver that is responsible for changing the meaning for its use. Thus there may be an extra invariant assertion that detects the invalid information and initiates a business response. Over the long run these failures may be manage by changing (installing) invariant checks in the source assertion. The supplying Authority has more constraints.
Invariants may be implemented by an authority as specified for the assertion they are determining. Or an automatic assertion identifies deviations and issues information to deal with the exception. Such as informing an authority. Usually a manual assertion.
Entity
A model element defined by identity, not attributes. Entities are identified where the business tracks something over time with continuity and authority. If you are planning an implementation and identifying Entities you must use data modeling techniques. Building a logical data model in a recognized modeling tool will reveal relationships that are important in the design.
Particularly the composite entities that capture many to many relationships.
If the attributes of an assertion include an id then this suggests an entity. It is important to identify the assertion that assigns the id originally. It makes a statement that this is an object that will be recognized throughout a number of decisions. And it recognizes that other assertions may use this as a context. The decision will be informed by information available using the id as a key. In an implementation this will be a query into a datastore. When an assertion is identifies input that would require a query to pull a connection then the feeding assertion is likely an indication of a persistent object.
A good example of this is a part or product. Is the Part a categorization of all part like objects or an serial number? In Order Entry it is an identification of all objects that are interchangeable. This might have a UPC obtained by the manufacturer. But commonly a SKU is assigned by the part supplier and applies only to their system. In that case it is the Product Manager who creates and assigns the unique id.
Is the ID the internal id used as a primary key in a data base or will it be entered by users of the system. A typical example is where a customer wishes to uniquely identify what they want to purchase. Or someone wishes to obtain details about what they will obtain.
In this case the part identifier (lets call it an SKU) is assigned when the part is identified. It may be that instances of this are obtained from different suppliers. They will be stored in different warehouses. In some cases there may be a unique identifier for each part of object(a serial number) perhaps used to manage returns to the supplier.
But in making implementation decisions the necessity of having a managed part identifier is paramount. It will be the handle for much discussion about an order. And a value object might be related to a SKU. ( customer might attach a-fits-my-car, is-affordable, is-available record to it to compare possible purchases). The customers table will include a SKU but will require a supplier to be sure it is unique.
But back to identifying DDDEntities from an AM.
An assertion includes an boolean for capturing if the information produced is an organizational record. these assertions indicate the need for persistence. and a need to maintain information permanently, usually stored in a database structure.
A create id assertion will be identified. The guidance for managing these business objects(particularly those that are used as widely as SKU) will have to be manage carefully. In some cases changes initiated by this assertion will have to initiate messages to inform other Authorities of the change. An authority may not recognize there is a new part available when it changes in the assertion that lists it.
In building the AM and in specifying the assertions to be implemented the Implementation Note for the particular implementation should identify the guidance needed to create the persistence structure needed. This will show in the implementation requirements.
In DDD a Use Case is always within one bounded context. says Eric Evans according to CoP
The Infrastructure Layer
It delivers a number of ‘Repository Operations’ to load and save or update etc. The repository abstracts persistence
Repository
A DDD term that exposes repository operations. So an Entity might have the job of persisting the change in the repository. But only if the assertion states or implies this. And the Repository (there are a number of them. Billing, Order etc) must have a clear responsibility. Is there an Authority called the Order Repository Manager or Order DataStore Manager? This concept is specifically needed for suitable Information Management. But a Repository does not necessarily match a DB table. It could be a set of tables or a NoSQL store. Bit most important is that the Entity that uses the Repository asks it to store and retrieve information created or used in assertions. The Entity that implements the retrieve or store (CQRS and AM separates these, while the Entity might not: because it sits on the repository). There is a conundrum in what is stored. Is it the frame(which might be complex, and could be stored as a json or unraveled into tables). Or is there an assertion that ‘understands’ the rationale of the set of tables that work together and integrate to produce a a more complex datastore that has a more solid coherence.
If we think about warehousing, the coherent datastore is desirable, and it implies that invariants will have to ensure the coherent meaning.
This is a very difficult implementation decision that has a future impact on how assertions might grow to better provide coherent organizational pictures to inform decisions.
Does this mean that a more fragmented view should be implemented or a bigger investment in future business description should be accommodated early. This must be taken out of the hands of IT. And it must be considered in implementation. That means the implementation design should have guiding governance assertions.
Aggregate
CoP says an Aggregate is another conceptual boundary; you could not differentiate it from an entity in code!