Model-Code Bridge

It's important for us to avoid the model-code gap, therefore we'll have to have a bridge from our Technology Vision and our Architecture Vision to our code. The bridge that we will use currently is on how we manage our package structure, tactical designs, and the way we manage our infrastructure.

Package Structure

The top most level of our packages are our git repositories. By convention, we will always have a repository that represent a system or a bounded context. In each of the repository, it will further contain modules that are created as a result of marrying up our context map and layered architecture. In overall, the convention will look like this:

• {systemName} / {subdomainName}
  • packages
    • {contextName}-{layerName}
    • {contextName}-{layerName}
    • {contextName}-{layerName}

The above convention will be suitable for the majority of the case to avoid the model-code gap. Whenever there are cases where the above convention does not fit, for example, our webapp, do shout or reflect the change in the design (either architecture or technology vision).

As the number of packages that we have changed fairly quickly, therefore the actual package structure will not be captured in this documentation. To give an example of how it would look like in reality:

• som
  • packages
    • som-search-data
    • som-search-driven
    • som-webapp
• pro
  • packages
    • pro-billing-driven
    • pro-billing-domain
    • pro-webapp

Tactical design

Naturally beneath our packages, that's where our code lives. We don't want to stop our effort to reduce the model-code gap at the package structure, we also want our code to be as close as our model. We are using a lot of UML to visualise our designs at the moment and they can be found at the Tactical Design section on the sidebar.

Infrastructure

Our systems are built on AWS. It is a good practice in AWS to create separate AWS accounts to introduce isolation. The decision on whether we want to create a new account or not is derived from our Technology Vision. One system should equate to one AWS account.