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

# 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: 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.

When this file changes, someone has to apply those to the codebase and database. If your domain is concentrated into one project that's simple, but if you have domain knowledge spread across different projects, with only humans working on it, there's a change that from times to times someone will forget to update all something properly, especially when it doesn't trigger any CI error.

(In both scenarios documentation is seldom updated)

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 projects

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 project's domain perspective which may be slightly different from what you want, causing weird changes on the domain files just to accommodate one project's needs - something which would be mitigated with contexts.