12 lines
1.3 KiB
Markdown
12 lines
1.3 KiB
Markdown
You have two types of components:
|
||
|
||
1. Business components
|
||
2. Autonomous components
|
||
While you should probably only have 1 or 2 BCs in a service, you will have many more ACs. The number of ACs you have will be proportional to the number of systems your service participates in. An AC is responsible for one or more message type. Its message handlers could be real (server-side) message handlers on the bus, or could be javascript event message handlers--or, whatever else. Multiple ACs can be hosted together.
|
||
|
||
- Don't try to reuse code between ACs.
|
||
- Strive for "disposable" code
|
||
- Solve for today's problem - not tomorrow's (JFHCI = just frickin' hard code it)
|
||
**Shades of Physical Autonomy**
|
||
We can have everything deployed into one shared space. We can put parts of a performance-sensitive AC to their own environments. Or, we could just deploy the entire AC to it's own location. SOA = business value. ACs help us to deploy separately, so that we can deploy high-value components out from their current location to another where it will perform better. **Summary**
|
||
The runtime environment is not made up of services. Services are logical organizational constructs. ACs are the deployment components. Commands are sent within service boundaries. One AC in one service would not send a message to an AC in another service. |