A sample accounting project with best practices in software design for simple & safe code respecting accounting standards.
the process of being mentally stimulated to do or feel something, especially to do something creative.
This project is certainly inspired by many years of experience working with awesome colleagues and complex systems, making it clear that functional programming can be very useful for software in all business areas.
It's also inspired by a few books that you definitely should read.
- Grokking Simplicity: Taming complex software with functional thinking by Eric Normand (ISBN 9781617296208)
- Grokking Functional Programming by Michał Płachta (ISBN 9781617291838)
- Domain-Driven Design: Tackling Complexity in the Heart of Software, 1st edition by Eric Evans (ISBN 9780321125217)
- Implementing Domain-Driven Design by Vaughn Vernon (ISBN 9780321834577)
Thank you all \o/ -- colleagues, companies and authors.
Accounting is a clear use case for event sourcing, where data MUST NOT be simply updated. Instead of that, every change MUST be appended to a journal, where all transactions are logged individually. After that, they can be aggregated to support different needs. e.g. specific journals or financial reports.
This project was designed according to practices defined by domain-driven design -- making use of events, aggregates, entities and strongly typed values as value objects, avoiding anemic classes.
Of course, as this project is simply an example, with clear domain and bounded context, there's no need for strategic design, so it's basically applying tactical design with events and aggregates.
This project also applies a little bit of functional programming paradigm, with pure functions and immutable values, avoiding unexpected side effects.
Of course at some point some mutation needs to be done, some state needs to be changed, but such mutations are deferred as much as possible.
Inspired by the "Mostly adequate guide to FP in Javascript", functions are
designed to return Either<E, A> -- where E is an error type, and A is the
actual result type, in case of success.
p.s. this project is not making full use of functional programming. The core
classes and methods are purely functional, as much as multi-paradigm languages
like TypeScript and JavaScript can be. There's much more in FP than
immutability, pure functions and pure error handling. This project is a basic,
minimal implementation of FP.
p.s. you can learn more about pure error handling and Either<E, A>
in a specific chapter of the guide mentioned above.
Functions that would normally mutate a value, have been designed to actually
return a specific type Mutation<MutantType, EventType> containing
mutant: MutantType and events: EventType[] that caused the mutation.
That avoids impure functions & provides any events that need to be stored in the event store for event sourcing.
In other words, a new value with different state is returned without changing the state of the original value, but including the events that caused the new state.
Example
const mutation: Mutation<CustomerAccount, CustomerAccountEvent> =
customerAccount.allocatePayment(payment, currentDateTime)
const updatedCustomerAccount: CustomerAccount = mutation.mutant
const events: CustomerAccountEvent[] = mutation.eventsA statically typed programming language makes the software more safe to run and more easy to understand and work with. Avoiding run-time errors is a great benefit, as well as knowing what types to expect as arguments and return values.
TypeScript is a very popular language, therefore more people and companies get a chance to understand and experiment event sourcing, domain-driven design and functional programming paradigm.
Unfortunately that's not the case for Haskell or other purely functional programming languages.