Composable provides tooling for normal modern architecture projects.
By modern architecture we mean software that tend to use tools or designs with labels such as Event Driven Architecture, Event Driven SOA, CQRS, Microservices, NoSql, Event Sourcing etc.
By normal projects we mean the vast majority of projects. Projects where reliability, productivity and maintainability are the top priorities. Projects where extreme scalability and availability are not required.
Unfortunately, it seems to us that most modern architecture tooling and platforms do not target normal projects. Instead they sacrifice reliability on the altar of nominal scalability and availability. In our experience this tends to result in a complexity explosion as the developers try to build reliable software with tooling not designed for reliability. Ultimately scalability and availability often disappear along with both productivity and maintainability as the complexity skyrockets.
Composable consistently prioritizes reliability, productivity and maintainability for normal projects. Therefore all our tools fully support the following:
Transactions and TransactionScope.
High performance black box testing using the real production components.
Renaming and moving classes already persisted in production data without breaking production data
Renaming properties and fields without breaking production data (using Newtonsoft.Net attributes)
Powerful semantic event modelling paradigm
Compile time and runtime design validation catching all known common design mistakes.
A unified messaging platform that gives you
Powerful zero configuration routing
A service bus with an exactly-once delivery guarantee
RPC style communication with optional command deduplication
Letting you build
Type safe Hypermedia APIs that can be consumed with with full intellisense and type safety in
.Net language clients such as ASP.Net or Blazor (Blazor support not yet implemented)
Typescript (Not yet implemented)
All the features from How Composable components are different
Build complex aggregates nesting entities and components in each other to arbitrary depths with ease by leveraging semantic events.
Refactoring of event histories including fully removing obsolete code
Performant on-demand generation of query models from events dramatically reduces the need for persisted query models
All the features from How Composable components are different
Save or load instances of any class serializable with Newtonsoft.Json with a single line of code.
Automatically tracks and persists changes to loaded documents
All the features from How Composable components are different
Most APIs consist of a number of service classes and interfaces. Imagine instead an APIs that is a lot like a website. That had a start resource from which you follow links to other resources where you could fill in commands and post them. That is essentially what a Hypermedia API is. Hypermedia API have these advantages among others:
You expose zero implementation details about your API. Clients only know about the hypermedia controls such as commands, resources and links.
Developers don’t need to read a ton of documentation to figure out how to use your API or what functionality is available. Instead they just follow the links using intellisense from your start-resource to explore the functionality.
Simply means that you declare how the meaning of one event relates to the meaning of another through .Net interface inheritance. As it turns out this enables very flexible and powerful domain designs with complex aggregates, zero configuration routing and elimination of a ton of duplicated event handler code.