Home

Hubi is like a database migration tool but for ubiquitous language i.e. it reads some of your versioned files to write code, data schema and documents. By automating this, you have:

1. A documented language of the domain: it's easier for people to catch up on your domain and spot errors on how it is modeled;

2. A repeatable structure: it's possible to automate part of the software/documents writing relative to your domain. keeping it consistent;

3. The domain progress: it's easy to check how the domain has evolved over time.

Example

 # Domain file @ project/src/domain/user.yml
 name: User
 description: A person who has an account
 attributes:
   - name: name
     description: How to address the person
     required: true
   - name: eyes
     description: The color of the user's eyes
+    deprecated:
+    - message:
+        We've discovered that this is a useless information for us.
+        Will be deprecated soon
+    - error: false
-    required: true
+    required: false
+  - name: birthday
+    comment: This field was added later
+    type: date
+    required: false

You just read this file and understood that the domain it belongs to has the concept of users which needs to be "translated" into the code, and, if storage is necessary, into a data schema too.

The higlighted changes will have to be done to the codebase and database. If your domain is concentrated into one repository that's simple, but if it is spread across different repositories, with only humans working on it, there's a chance that from times to times someone will forget to update something properly, especially when it doesn't trigger any CI error.

(In both scenarios documentation is seldom updated anyway)

If you let hubi apply the changes for you, it'll create the code, the data schema and documentation, every time. You'll be free to focus on "translating" the domain rules to software without worrying about eventual inconsistencies.

Just run the command below to make hubi read the file, and start working:

$ npm run my-custom-hubi-script
> hubi save --same-folder --translator joi & hubi save --output documents --translator site

Spreading domain knowledge in different repositories

Hubi doesn't enforce any rule on how to share knowledge (monorepo/services, dependencies/submodules/subtrees, etc). It is totally up to you.

I personally embed a git repository, dedicated to the domain files, as a subtrees into the ones interested in my domain. I've only used this scenario for personal projects, so I don't know how well it plays with more people.

When to use hubi

Whenever you want to share domain knowledge with different stakeholders, especially people who wouldn't look at the code.

When it comes to code, it really worthes when your domain allows you to do so. If it doesn't, you're only going to be reusing another repository's domain perspective which may be slightly different from what you want, causing weird changes on the domain files just to accommodate one repository's's needs - something which would be mitigated with contexts.