How all this works: The fundamental abstractions

The first problem of developing a new software application is to determine what it does. The second problem is to decide the fundamental abstractions that will govern the system. If you don't figure this out early, you'll either write a hideous pile of rotting spaghetti that no one will want to maintain, or you'll do that and change careers entirely.

Sorting the "what it does" problem often makes the "what represents it" question easier to answer. If you want to build a building, for example, having a clear idea of what it does ("it provides living space for lots of people") should give you a good idea of its fundamental abstraction ("people live in apartments" or "people live in houses"). If you get the fundamental abstraction wrong, it just won't work ("people live in cubicles"). This is why airports with huge shopping centers don't feel right, and condos carved out of de-sanctified churches look weird.

Fortunately, the first fundamental abstraction of this project was obvious, even before I decided to make a blog engine its first realization. Everything in the Inner Drive Journal is an Event.

Now, I'm an old Object Oriented guy. So when describing software concepts, I think of classes that have is-a and has-a characteristics. So an Event is a thing that has or will happen, and has a start time, type, and name, and maybe other characteristics like an end time, a location, comments, and text. (Because the Event lives inside a software system, it also is a DataItem that has an ID, created time, modified time, and control bits to determine whether it's published, deleted, or test data.)

This means that everything that everything you see on The Daily Parker is, fundamentally, an Event. A BlogPost is an event that has additional characteristics specific to blogging. In time, I'll add other event types with other characteristics, for example to represent when I read a book or took a hike with Cassie.

The blog post's class hierarchy looks like this:

public class BlogPost : Event { }

public class Event : DataItem, IEvent, IGeoLocatable { }

public abstract class DataItem : IDataItem, IAuthorizable { }

The I prefix indicates an interface, which simply defines what a thing has to have without specifying how any of those characteristics work. That lets developers care only about the minimum characteristics of a thing without caring about what the thing actually is. For example, the authorization system only cares that things implement the IAuthorizable interface, and doesn't care if the thing is a blog post, a book review, or a squirrel.

The other principal abstraction is a Project, which is a collection of Events. There are two reserved projects, Public and Administration, but otherwise what goes in a Project is completely arbitrary. The Daily Parker is a Project containing Events, and most (but not all) of those Events are Blog Posts.

The application has two other things that people interact with, Users and Comments. But altogether, the application has (as of this morning) about 50 other classes that are and have specific characteristics that make the application work. For example, the View page is a class that includes the Blazor page definition, the code behind the page, and a list of text items like field names and tooltips.

As always, use the comments to ask questions or ask for specific topics of these explainers.

Next time: the authorization architecture, which is how the application decides who can see and do what.