Machb Project
Introduction
The goal of the architect is to create a shape for the system that recognizes policy as the most essential element of the system while making the details irrelevant to that policy. This allows decisions about those details to be delayed and deferred.
— ©Robert C. Martin
Project structure
A module should be responsible to one, and only one, actor.
— ©Robert C. Martin
Machb project contains following parts:
- Core - (aka Packages) this is aggregator all shared modules for building application.
- Apps - (aka Application) contains builds of different implementation set of target projects, and use for end-to-end testing and as an examples and reference implementation.
- MachaOn - (aka Infrastructure) completed variants of demo builds.
People who want to reuse software components cannot, and will not, do so unless those components are tracked through a release process and are given release numbers.
— ©Robert C. Martin
Tech stack
Don’t marry the framework!
There are some frameworks that you simply must marry. If you are using C++, for example, you will likely have to marry STL—it’s hard to avoid. If you are using Java, you will almost certainly have to marry the standard library.
That’s normal — but it should still be a decision. You must understand that when you marry a framework to your application, you will be stuck with that framework for the rest of the life cycle of that application. For better or for worse, in sickness and in health, for richer, for poorer, forsaking all others, you will be using that framework. This is not a commitment to be entered into lightly.
— ©Robert C. Martin
For the internal layers core projects we can use only general technology:
- Node.js (19.8.1)
- npm (9.5.1)
- TypeScript (4.1.6)
For the outer layers and all layers for the target (Apps) projects we can use everything we need:
- React (17.0.1)
- Vue (3.0.0)
- AWS
- GCP
- Azure
Tools:
- Lerna (6.5.1)
- tsuml2
- typedoc
- Visual Studio Code
Architecture
Machb project following Clean Architecture rules.
Clean Architecture is a software design philosophy introduced by Robert C. Martin, also known as Uncle Bob. It emphasizes the separation of concerns which divides the software into layers making it easier to manage and maintain. The main goal of Clean Architecture is to produce a system that is independent of frameworks, UI, database, and any external agency. In other words, it appss at creating software that is loosely coupled, highly maintainable, and scalable. Core Concepts of Clean Architecture:
- Independent of Frameworks: The architecture does not rely on the existence of some library of feature-laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints.
- Testable: The business rules can be tested without the UI, database, web server, or any other external element.
- Independent of UI: The UI can easily change without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
- Independent of Database: You can swap out Oracle or SQL Server for MongoDB, BigTable, CouchDB, or something else. Your business rules are not bound to the database.
- Independent of any external agency: In fact, your business rules simply don’t know anything at all about the outside world.
The Layers of Clean Architecture:
©Robert C. Martin
Project structure
Install & Build
- npm install
- npm run build
License
Apache 2