timjstewart (3) [Avatar] Offline
Hello Debasish,
My name is Tim Stewart and I'm a software developer. I am very excited about your current book and would be happy to review it if you still need reviewers.

I was just re-reading Barbara Liskov's "Program Development in Java" and a few concepts finally clicked together in my head. They seem to be relevant to your book. There is a 99.9999% chance that your book already touches on these concepts and how they fit together but just in case it doesn't (and you find them to be relevant), I thought I'd drop you this note.

1. When designing a system, a domain model can be represented as a graph where each entity in the domain is a node in the graph, and relationships between entities are modeled as edges between nodes (e.g. you might have an Account node and an Invoice node connected by a directed "paid" edge to represent paid invoices in an account).

2. Each node represents a set of entities (e.g. the Account node represents all Account objects in the system).

3. An edge between two nodes represents a function from one entity to another (e.g. invoiceAccount : Invoice -> Account).

4. Some functions (derived from edges) have inverses (conceptually at least) (e.g. accountInvoices : Account -> Set[Invoice]).

Once I start viewing my domain in terms a graph of sets, and functions over sets, I can bring in all sorts of mathematical ideas to reason about my system. I can use existential and universal quantifiers, functional composition to traverse relations, set theory, graph theory, and so on. Some of these ideas can be used to express Hoare Triples when specifying behavior of functions. I would think (though I'm not sure) that Category Theory might also play a valuable role.

I also just re-read Alexander Stepanov's book, "From Mathematics to Generic Programming" and he talks about the power of Abstract Algebra in programming (e.g. in order to be truly generic, you must be very specific about what your algorithms depend on from the types it operates on). Using Abstract Algebra we can see that an Invoice might be a Monoid in the sense that you may be able to combine two invoices into one. Identifying what axioms a set and its operations support can help you reason about your system using very precise language. For example, knowing that an operation is commutative adds more flexibility around parallelizing that operation across a set of objects.

I think that all these mathematical ideas dovetail very nicely with the area of denotational semantics but I haven't explored the connections very deeply yet.

Thanks for reading this!

Debasish Ghosh (111) [Avatar] Offline
Hi Tim -

Thanks for your comments.

Regarding review of the book you need to be in touch with the publisher Manning - they decide all reviewers for the book.

Now back to your thoughts on the mathematical concepts in domain modeling. In the book I talk about many of the mathematical stuff that you mentioned but mostly without the rigor of the theory. By theory I mean category theory which models many of the concepts that I use in the book.

One of the things which has been emphasized a lot in the book is the concept of algebraic design - I view the model contract as an algebra based on the types and morphisms (or functions) and derive lots of structures from there. e.g. I talk about monoids and demonstrate how various domain model artifacts can be modeled as monoids. I talk about functors, applicatives and monads and map them to real world domain modelling structures.

In brief the book has an underlying mathematical undercurrent though the discussions are purely based on implementations using the functional programming techniques.

timjstewart (3) [Avatar] Offline
Thank you for your response Debasish. I'm even more interested in reading your book now. Thanks in advance!