Fmodel
#Discover#Design#Develop#Deploy
Achieve complete automation of information flow and business processes
Domain Modeling
There are a few key considerations to keep in mind when creating a domain model. First, it's important to ensure that the model accurately reflects the domain and the relationships between the concepts within it. This may require research and consultation with domain experts.
Second, it's important to ensure that the model is intuitive and easy to understand for stakeholders. This may require the use of clear and concise language, as well as the use of visual elements such as diagrams to aid comprehension.
Finally, it's important to ensure that the model is flexible and able to adapt to change.
Event Modeling
Event Modeling is an effective technique to discover a domain. It is a method of describing systems using an example of how information has changed within them over time. Specifically this omits transient details and looks at what is durably stored and what the user sees at any particular point in time. These are the events on the timeline that form the description of the system.
We can show, by example, what a system is supposed to do from start to finish, on a time line and with no branching.
f { model } / Software Model
The f { model } library is implementing the event model in a general way. It promotes clear separation between data and behaviour. It provides just enough tactical Domain-Driven Design patterns, optimised for Event Sourcing and CQRS.
The flow is parametrized with Command, Event, and State parameters. The responsibility of the business is to specialize in their case by specifying concrete Commands, Events, and State. For example, Commands=IssueInvoice, CreditAccount; Events=InvoiceIssued, AccountCredited, State=Account(with list of attributes: name, amount).
Specification By Example
Specification By Example is a collaborative approach to software development, analysis and testing. It is the fastest way to align people from different roles on what exactly we need to build and how to test it.
The requirements are presented as scenarios. A scenario is an example of the system’s behavior from the users’ perspective, and they are specified using the Given-When-Then structure to create a testable specification.
The specification is written in the form of executable tests that are automated and can be run continuously. Tests cover the full range of scenarios, from happy paths to errors.
