Architectural Way of Catching Business Functionality Explained
An agile architecture should be designed in the way it aligns to the business requirements, thus focusing on the software parts that directly amplify business value and enhance adaptation capability (reaction to change).
These requirements have to be documented using semantic that is perfectly understood by all project teams and using syntax that can be afterwards effectively and efficiently used by the developers, who will develop the system. The trivial helper like user stories defined based on the predefined syntax (as a ... I'd like to have etc.) are good but far not enough to catch the core of the business requirements. They focus on the single activity of a system even if cohesive grouped together. To describe business functionality you need a "holistic" instrument. We need business models.
For the sake of description of a business functionality it is enough to create three types of models:
System state model describes all states that a certain software system and their core business entities can have. It is the ultimate tool to reason about system's complexity.
Additionally this model describes transitions between states with constraints that rule them.
A system state can be best modeled using UML state machine diagram.
Business entity and process model describes all core business entities and processes that a software system implements and supports. This model can be quite complex and consists of many sub-models.
Model of business entities describes core elements of a system with their properties and relations with causalities between them.
Models of business processes depict how the system manipulates (creates, changes, deletes etc.) business entities allowing actual execution of the business.
Additionally, during the modelling phase, an ubiquitous language emerges, means a glossary used by all project teams and stakeholders.
A business entities model can be best modeled using UML class diagram (however these entities are not your DTOs, database objects or similar! They are business entities!).
The best way to model business processes is to use BMPN notation.
Even if both above models contain information about business logic you need an explicit model to describes the business rules.
These rules can be divided into two groups, validation rules and plausibility rules.
The former check if the business operative data is in a valid state. The later defines Boolean expressions to evaluate on the data, constraints to run them, variants and in-variants (what changes and what not), and finally the actions to be performed based on the results.
The rule model can be expressed using DMN notation or just a simple table.
Yeah, that's it. If you have all of the models, then you can insist you have the business functionality under control :). However please do not overuse them. Simplicity is the cure.
These requirements have to be documented using semantic that is perfectly understood by all project teams and using syntax that can be afterwards effectively and efficiently used by the developers, who will develop the system. The trivial helper like user stories defined based on the predefined syntax (as a ... I'd like to have etc.) are good but far not enough to catch the core of the business requirements. They focus on the single activity of a system even if cohesive grouped together. To describe business functionality you need a "holistic" instrument. We need business models.
For the sake of description of a business functionality it is enough to create three types of models:
- System state model
- Business entity and process model
- Business rule model
System state model describes all states that a certain software system and their core business entities can have. It is the ultimate tool to reason about system's complexity.
Additionally this model describes transitions between states with constraints that rule them.
A system state can be best modeled using UML state machine diagram.
Business entity and process model describes all core business entities and processes that a software system implements and supports. This model can be quite complex and consists of many sub-models.
Model of business entities describes core elements of a system with their properties and relations with causalities between them.
Models of business processes depict how the system manipulates (creates, changes, deletes etc.) business entities allowing actual execution of the business.
Additionally, during the modelling phase, an ubiquitous language emerges, means a glossary used by all project teams and stakeholders.
A business entities model can be best modeled using UML class diagram (however these entities are not your DTOs, database objects or similar! They are business entities!).
The best way to model business processes is to use BMPN notation.
Even if both above models contain information about business logic you need an explicit model to describes the business rules.
These rules can be divided into two groups, validation rules and plausibility rules.
The former check if the business operative data is in a valid state. The later defines Boolean expressions to evaluate on the data, constraints to run them, variants and in-variants (what changes and what not), and finally the actions to be performed based on the results.
The rule model can be expressed using DMN notation or just a simple table.
Yeah, that's it. If you have all of the models, then you can insist you have the business functionality under control :). However please do not overuse them. Simplicity is the cure.
Comments
Post a Comment