@mytechtoday/augment-extensions 1.2.1 → 1.2.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.md +33 -1
- package/README.md +3 -3
- package/augment-extensions/domain-rules/software-architecture/README.md +143 -0
- package/augment-extensions/domain-rules/software-architecture/examples/banking-layered.md +961 -0
- package/augment-extensions/domain-rules/software-architecture/examples/ecommerce-microservices.md +990 -0
- package/augment-extensions/domain-rules/software-architecture/examples/iot-eventdriven.md +882 -0
- package/augment-extensions/domain-rules/software-architecture/examples/monolith-to-microservices-migration.md +703 -0
- package/augment-extensions/domain-rules/software-architecture/examples/serverless-imageprocessing.md +957 -0
- package/augment-extensions/domain-rules/software-architecture/examples/trading-eventdriven.md +747 -0
- package/augment-extensions/domain-rules/software-architecture/module.json +119 -0
- package/augment-extensions/domain-rules/software-architecture/rules/challenges-solutions.md +763 -0
- package/augment-extensions/domain-rules/software-architecture/rules/definitions-terminology.md +409 -0
- package/augment-extensions/domain-rules/software-architecture/rules/design-principles.md +684 -0
- package/augment-extensions/domain-rules/software-architecture/rules/evaluation-testing.md +1381 -0
- package/augment-extensions/domain-rules/software-architecture/rules/event-driven-architecture.md +616 -0
- package/augment-extensions/domain-rules/software-architecture/rules/fundamentals.md +306 -0
- package/augment-extensions/domain-rules/software-architecture/rules/industry-architectures.md +554 -0
- package/augment-extensions/domain-rules/software-architecture/rules/layered-architecture.md +776 -0
- package/augment-extensions/domain-rules/software-architecture/rules/microservices-architecture.md +503 -0
- package/augment-extensions/domain-rules/software-architecture/rules/modeling-documentation.md +1199 -0
- package/augment-extensions/domain-rules/software-architecture/rules/monolithic-architecture.md +351 -0
- package/augment-extensions/domain-rules/software-architecture/rules/principles.md +556 -0
- package/augment-extensions/domain-rules/software-architecture/rules/quality-attributes.md +797 -0
- package/augment-extensions/domain-rules/software-architecture/rules/scalability-performance.md +1345 -0
- package/augment-extensions/domain-rules/software-architecture/rules/security-architecture.md +1039 -0
- package/augment-extensions/domain-rules/software-architecture/rules/serverless-architecture.md +711 -0
- package/augment-extensions/domain-rules/software-architecture/rules/skills-development.md +568 -0
- package/augment-extensions/domain-rules/software-architecture/rules/tools-methodologies.md +961 -0
- package/augment-extensions/workflows/beads/rules/workflow.md +1 -1
- package/modules.md +40 -3
- package/package.json +1 -1
|
@@ -0,0 +1,554 @@
|
|
|
1
|
+
# Industry-Specific Architectures
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
This document covers specialized architectural patterns for industry-specific domains including IoT, AI/ML, blockchain, and edge computing systems.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Knowledge
|
|
10
|
+
|
|
11
|
+
### IoT (Internet of Things) Architecture
|
|
12
|
+
|
|
13
|
+
**Core Components**
|
|
14
|
+
- **Device Layer**: Sensors, actuators, embedded systems
|
|
15
|
+
- **Gateway Layer**: Protocol translation, data aggregation, edge processing
|
|
16
|
+
- **Platform Layer**: Device management, data ingestion, analytics
|
|
17
|
+
- **Application Layer**: User interfaces, business logic, integrations
|
|
18
|
+
|
|
19
|
+
**Communication Protocols**
|
|
20
|
+
- MQTT (Message Queuing Telemetry Transport) - lightweight pub/sub
|
|
21
|
+
- CoAP (Constrained Application Protocol) - RESTful for constrained devices
|
|
22
|
+
- AMQP (Advanced Message Queuing Protocol) - reliable messaging
|
|
23
|
+
- HTTP/HTTPS - web-based communication
|
|
24
|
+
|
|
25
|
+
**Key Patterns**
|
|
26
|
+
- **Device Shadow**: Cloud representation of device state
|
|
27
|
+
- **Command and Control**: Remote device management
|
|
28
|
+
- **Telemetry Streaming**: Real-time data collection
|
|
29
|
+
- **Firmware Over-The-Air (FOTA)**: Remote updates
|
|
30
|
+
|
|
31
|
+
### AI/ML Architecture
|
|
32
|
+
|
|
33
|
+
**Training Pipeline**
|
|
34
|
+
- Data collection and labeling
|
|
35
|
+
- Feature engineering
|
|
36
|
+
- Model training and validation
|
|
37
|
+
- Hyperparameter tuning
|
|
38
|
+
- Model versioning and registry
|
|
39
|
+
|
|
40
|
+
**Inference Pipeline**
|
|
41
|
+
- Model serving (batch vs. real-time)
|
|
42
|
+
- A/B testing and canary deployments
|
|
43
|
+
- Model monitoring and drift detection
|
|
44
|
+
- Feedback loops for continuous learning
|
|
45
|
+
|
|
46
|
+
**MLOps Components**
|
|
47
|
+
- **Data Versioning**: DVC, Delta Lake
|
|
48
|
+
- **Experiment Tracking**: MLflow, Weights & Biases
|
|
49
|
+
- **Model Registry**: Centralized model storage
|
|
50
|
+
- **Feature Store**: Reusable feature definitions
|
|
51
|
+
- **Monitoring**: Performance, drift, bias detection
|
|
52
|
+
|
|
53
|
+
**Deployment Patterns**
|
|
54
|
+
- **Embedded Models**: On-device inference (mobile, edge)
|
|
55
|
+
- **Model as a Service**: REST API endpoints
|
|
56
|
+
- **Batch Prediction**: Scheduled inference jobs
|
|
57
|
+
- **Stream Processing**: Real-time predictions on event streams
|
|
58
|
+
|
|
59
|
+
### Blockchain Architecture
|
|
60
|
+
|
|
61
|
+
**Core Components**
|
|
62
|
+
- **Nodes**: Full nodes, light nodes, validator nodes
|
|
63
|
+
- **Consensus Mechanism**: PoW, PoS, PBFT, Raft
|
|
64
|
+
- **Smart Contracts**: Self-executing code on blockchain
|
|
65
|
+
- **Distributed Ledger**: Immutable transaction history
|
|
66
|
+
|
|
67
|
+
**Architecture Patterns**
|
|
68
|
+
- **Public Blockchain**: Permissionless, fully decentralized (Bitcoin, Ethereum)
|
|
69
|
+
- **Private Blockchain**: Permissioned, controlled access (Hyperledger Fabric)
|
|
70
|
+
- **Consortium Blockchain**: Semi-decentralized, multiple organizations
|
|
71
|
+
- **Hybrid Blockchain**: Combination of public and private
|
|
72
|
+
|
|
73
|
+
**Design Considerations**
|
|
74
|
+
- Immutability vs. data privacy (GDPR compliance)
|
|
75
|
+
- Transaction throughput and latency
|
|
76
|
+
- Smart contract security and auditing
|
|
77
|
+
- Gas optimization (for Ethereum-based systems)
|
|
78
|
+
- Off-chain storage for large data
|
|
79
|
+
|
|
80
|
+
### Edge Computing Architecture
|
|
81
|
+
|
|
82
|
+
**Edge Hierarchy**
|
|
83
|
+
- **Far Edge**: Devices and sensors (IoT endpoints)
|
|
84
|
+
- **Near Edge**: Gateways and local servers
|
|
85
|
+
- **Regional Edge**: Edge data centers
|
|
86
|
+
- **Cloud**: Centralized cloud infrastructure
|
|
87
|
+
|
|
88
|
+
**Edge Patterns**
|
|
89
|
+
- **Data Filtering**: Process and filter at edge, send aggregates to cloud
|
|
90
|
+
- **Local Processing**: Real-time analytics at edge
|
|
91
|
+
- **Caching**: Store frequently accessed data at edge
|
|
92
|
+
- **Offline Operation**: Continue functioning without cloud connectivity
|
|
93
|
+
|
|
94
|
+
**Use Cases**
|
|
95
|
+
- Autonomous vehicles (low-latency decision making)
|
|
96
|
+
- Industrial IoT (real-time monitoring and control)
|
|
97
|
+
- Retail (in-store analytics and personalization)
|
|
98
|
+
- Healthcare (patient monitoring, medical imaging)
|
|
99
|
+
- Smart cities (traffic management, surveillance)
|
|
100
|
+
|
|
101
|
+
---
|
|
102
|
+
|
|
103
|
+
## Skills
|
|
104
|
+
|
|
105
|
+
### Designing IoT Systems
|
|
106
|
+
|
|
107
|
+
**Device Management**
|
|
108
|
+
```typescript
|
|
109
|
+
// Device shadow pattern
|
|
110
|
+
interface DeviceShadow {
|
|
111
|
+
reported: DeviceState; // Actual device state
|
|
112
|
+
desired: DeviceState; // Target device state
|
|
113
|
+
metadata: {
|
|
114
|
+
timestamp: number;
|
|
115
|
+
version: number;
|
|
116
|
+
};
|
|
117
|
+
}
|
|
118
|
+
|
|
119
|
+
class IoTDeviceManager {
|
|
120
|
+
async updateDesiredState(deviceId: string, state: Partial<DeviceState>) {
|
|
121
|
+
await this.shadowService.updateDesired(deviceId, state);
|
|
122
|
+
await this.publishCommand(deviceId, 'sync');
|
|
123
|
+
}
|
|
124
|
+
|
|
125
|
+
async handleReportedState(deviceId: string, state: DeviceState) {
|
|
126
|
+
const shadow = await this.shadowService.get(deviceId);
|
|
127
|
+
const delta = this.calculateDelta(shadow.desired, state);
|
|
128
|
+
|
|
129
|
+
if (delta) {
|
|
130
|
+
await this.publishCommand(deviceId, 'update', delta);
|
|
131
|
+
}
|
|
132
|
+
}
|
|
133
|
+
}
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
**MQTT Communication**
|
|
137
|
+
```typescript
|
|
138
|
+
// MQTT pub/sub for IoT
|
|
139
|
+
import mqtt from 'mqtt';
|
|
140
|
+
|
|
141
|
+
class IoTCommunication {
|
|
142
|
+
private client: mqtt.MqttClient;
|
|
143
|
+
|
|
144
|
+
connect(brokerUrl: string) {
|
|
145
|
+
this.client = mqtt.connect(brokerUrl, {
|
|
146
|
+
clientId: `device_${Date.now()}`,
|
|
147
|
+
clean: true,
|
|
148
|
+
qos: 1, // At least once delivery
|
|
149
|
+
retain: false
|
|
150
|
+
});
|
|
151
|
+
|
|
152
|
+
this.client.on('connect', () => {
|
|
153
|
+
this.client.subscribe('devices/+/commands', { qos: 1 });
|
|
154
|
+
});
|
|
155
|
+
}
|
|
156
|
+
|
|
157
|
+
publishTelemetry(deviceId: string, data: any) {
|
|
158
|
+
const topic = `devices/${deviceId}/telemetry`;
|
|
159
|
+
this.client.publish(topic, JSON.stringify(data), { qos: 1 });
|
|
160
|
+
}
|
|
161
|
+
}
|
|
162
|
+
```
|
|
163
|
+
|
|
164
|
+
### Implementing ML Pipelines
|
|
165
|
+
|
|
166
|
+
**Model Serving**
|
|
167
|
+
```python
|
|
168
|
+
# FastAPI model serving
|
|
169
|
+
from fastapi import FastAPI
|
|
170
|
+
from pydantic import BaseModel
|
|
171
|
+
import joblib
|
|
172
|
+
import numpy as np
|
|
173
|
+
|
|
174
|
+
app = FastAPI()
|
|
175
|
+
model = joblib.load('model.pkl')
|
|
176
|
+
|
|
177
|
+
class PredictionRequest(BaseModel):
|
|
178
|
+
features: list[float]
|
|
179
|
+
|
|
180
|
+
class PredictionResponse(BaseModel):
|
|
181
|
+
prediction: float
|
|
182
|
+
confidence: float
|
|
183
|
+
model_version: str
|
|
184
|
+
|
|
185
|
+
@app.post("/predict", response_model=PredictionResponse)
|
|
186
|
+
async def predict(request: PredictionRequest):
|
|
187
|
+
features = np.array(request.features).reshape(1, -1)
|
|
188
|
+
prediction = model.predict(features)[0]
|
|
189
|
+
confidence = model.predict_proba(features).max()
|
|
190
|
+
|
|
191
|
+
return PredictionResponse(
|
|
192
|
+
prediction=prediction,
|
|
193
|
+
confidence=confidence,
|
|
194
|
+
model_version="v1.2.0"
|
|
195
|
+
)
|
|
196
|
+
```
|
|
197
|
+
|
|
198
|
+
**Feature Store Pattern**
|
|
199
|
+
```python
|
|
200
|
+
# Feature store for ML
|
|
201
|
+
from datetime import datetime
|
|
202
|
+
from typing import Dict, List
|
|
203
|
+
|
|
204
|
+
class FeatureStore:
|
|
205
|
+
def __init__(self, storage):
|
|
206
|
+
self.storage = storage
|
|
207
|
+
|
|
208
|
+
def get_features(self, entity_id: str, feature_names: List[str]) -> Dict:
|
|
209
|
+
"""Retrieve features for online inference"""
|
|
210
|
+
features = {}
|
|
211
|
+
for name in feature_names:
|
|
212
|
+
key = f"feature:{name}:{entity_id}"
|
|
213
|
+
features[name] = self.storage.get(key)
|
|
214
|
+
return features
|
|
215
|
+
|
|
216
|
+
def write_features(self, entity_id: str, features: Dict, timestamp: datetime):
|
|
217
|
+
"""Write features for both online and offline use"""
|
|
218
|
+
# Online store (Redis)
|
|
219
|
+
for name, value in features.items():
|
|
220
|
+
key = f"feature:{name}:{entity_id}"
|
|
221
|
+
self.storage.set(key, value)
|
|
222
|
+
|
|
223
|
+
# Offline store (Data Lake)
|
|
224
|
+
self.storage.append_to_parquet(
|
|
225
|
+
f"features/{name}/date={timestamp.date()}",
|
|
226
|
+
{"entity_id": entity_id, **features, "timestamp": timestamp}
|
|
227
|
+
)
|
|
228
|
+
```
|
|
229
|
+
|
|
230
|
+
### Building Blockchain Applications
|
|
231
|
+
|
|
232
|
+
**Smart Contract Pattern**
|
|
233
|
+
```solidity
|
|
234
|
+
// Solidity smart contract example
|
|
235
|
+
pragma solidity ^0.8.0;
|
|
236
|
+
|
|
237
|
+
contract SupplyChain {
|
|
238
|
+
enum State { Created, InTransit, Delivered, Verified }
|
|
239
|
+
|
|
240
|
+
struct Product {
|
|
241
|
+
uint256 id;
|
|
242
|
+
string name;
|
|
243
|
+
address manufacturer;
|
|
244
|
+
address currentOwner;
|
|
245
|
+
State state;
|
|
246
|
+
uint256 timestamp;
|
|
247
|
+
}
|
|
248
|
+
|
|
249
|
+
mapping(uint256 => Product) public products;
|
|
250
|
+
mapping(uint256 => address[]) public productHistory;
|
|
251
|
+
|
|
252
|
+
event ProductCreated(uint256 indexed productId, address manufacturer);
|
|
253
|
+
event ProductTransferred(uint256 indexed productId, address from, address to);
|
|
254
|
+
event ProductStateChanged(uint256 indexed productId, State newState);
|
|
255
|
+
|
|
256
|
+
function createProduct(uint256 _id, string memory _name) public {
|
|
257
|
+
require(products[_id].id == 0, "Product already exists");
|
|
258
|
+
|
|
259
|
+
products[_id] = Product({
|
|
260
|
+
id: _id,
|
|
261
|
+
name: _name,
|
|
262
|
+
manufacturer: msg.sender,
|
|
263
|
+
currentOwner: msg.sender,
|
|
264
|
+
state: State.Created,
|
|
265
|
+
timestamp: block.timestamp
|
|
266
|
+
});
|
|
267
|
+
|
|
268
|
+
productHistory[_id].push(msg.sender);
|
|
269
|
+
emit ProductCreated(_id, msg.sender);
|
|
270
|
+
}
|
|
271
|
+
|
|
272
|
+
function transferProduct(uint256 _id, address _to) public {
|
|
273
|
+
Product storage product = products[_id];
|
|
274
|
+
require(product.currentOwner == msg.sender, "Not the owner");
|
|
275
|
+
require(_to != address(0), "Invalid address");
|
|
276
|
+
|
|
277
|
+
address previousOwner = product.currentOwner;
|
|
278
|
+
product.currentOwner = _to;
|
|
279
|
+
product.timestamp = block.timestamp;
|
|
280
|
+
|
|
281
|
+
productHistory[_id].push(_to);
|
|
282
|
+
emit ProductTransferred(_id, previousOwner, _to);
|
|
283
|
+
}
|
|
284
|
+
}
|
|
285
|
+
```
|
|
286
|
+
|
|
287
|
+
### Designing Edge Computing Systems
|
|
288
|
+
|
|
289
|
+
**Edge Processing Pattern**
|
|
290
|
+
```typescript
|
|
291
|
+
// Edge data processing with fallback to cloud
|
|
292
|
+
class EdgeProcessor {
|
|
293
|
+
private cloudEndpoint: string;
|
|
294
|
+
private localCache: Map<string, any>;
|
|
295
|
+
|
|
296
|
+
async processData(sensorData: SensorReading): Promise<ProcessedData> {
|
|
297
|
+
try {
|
|
298
|
+
// Try local processing first
|
|
299
|
+
const result = await this.processLocally(sensorData);
|
|
300
|
+
|
|
301
|
+
// Cache result
|
|
302
|
+
this.localCache.set(sensorData.id, result);
|
|
303
|
+
|
|
304
|
+
// Async sync to cloud (fire and forget)
|
|
305
|
+
this.syncToCloud(result).catch(err =>
|
|
306
|
+
console.error('Cloud sync failed:', err)
|
|
307
|
+
);
|
|
308
|
+
|
|
309
|
+
return result;
|
|
310
|
+
} catch (error) {
|
|
311
|
+
// Fallback to cloud if edge processing fails
|
|
312
|
+
return await this.processInCloud(sensorData);
|
|
313
|
+
}
|
|
314
|
+
}
|
|
315
|
+
|
|
316
|
+
private async processLocally(data: SensorReading): Promise<ProcessedData> {
|
|
317
|
+
// Local ML inference or rule-based processing
|
|
318
|
+
const prediction = await this.localModel.predict(data.values);
|
|
319
|
+
|
|
320
|
+
return {
|
|
321
|
+
id: data.id,
|
|
322
|
+
timestamp: Date.now(),
|
|
323
|
+
prediction,
|
|
324
|
+
processedAt: 'edge',
|
|
325
|
+
confidence: prediction.confidence
|
|
326
|
+
};
|
|
327
|
+
}
|
|
328
|
+
|
|
329
|
+
private async processInCloud(data: SensorReading): Promise<ProcessedData> {
|
|
330
|
+
const response = await fetch(`${this.cloudEndpoint}/process`, {
|
|
331
|
+
method: 'POST',
|
|
332
|
+
body: JSON.stringify(data),
|
|
333
|
+
timeout: 5000 // 5 second timeout
|
|
334
|
+
});
|
|
335
|
+
|
|
336
|
+
return response.json();
|
|
337
|
+
}
|
|
338
|
+
}
|
|
339
|
+
```
|
|
340
|
+
|
|
341
|
+
---
|
|
342
|
+
|
|
343
|
+
## Examples
|
|
344
|
+
|
|
345
|
+
### Example 1: Tesla OTA Update Architecture
|
|
346
|
+
|
|
347
|
+
**System Overview**
|
|
348
|
+
- Fleet of vehicles with embedded systems
|
|
349
|
+
- Over-the-air firmware updates
|
|
350
|
+
- Real-time telemetry collection
|
|
351
|
+
- Edge processing for autonomous driving
|
|
352
|
+
|
|
353
|
+
**Architecture Components**
|
|
354
|
+
|
|
355
|
+
1. **Vehicle Edge Layer**
|
|
356
|
+
- Autopilot computer (local inference)
|
|
357
|
+
- Sensor fusion (cameras, radar, ultrasonic)
|
|
358
|
+
- Local data logging and filtering
|
|
359
|
+
- Offline operation capability
|
|
360
|
+
|
|
361
|
+
2. **Gateway Layer**
|
|
362
|
+
- Cellular/WiFi connectivity
|
|
363
|
+
- Data compression and batching
|
|
364
|
+
- Update download and verification
|
|
365
|
+
- Rollback capability
|
|
366
|
+
|
|
367
|
+
3. **Cloud Platform**
|
|
368
|
+
- Fleet management dashboard
|
|
369
|
+
- Update distribution (CDN)
|
|
370
|
+
- Telemetry analytics
|
|
371
|
+
- ML model training pipeline
|
|
372
|
+
|
|
373
|
+
4. **Update Process**
|
|
374
|
+
```
|
|
375
|
+
1. Build firmware → Sign with private key
|
|
376
|
+
2. Upload to CDN → Staged rollout (1% → 10% → 100%)
|
|
377
|
+
3. Vehicle checks for updates → Downloads in background
|
|
378
|
+
4. Verify signature → Install during parked state
|
|
379
|
+
5. Rollback if issues detected → Report telemetry
|
|
380
|
+
```
|
|
381
|
+
|
|
382
|
+
**Key Design Decisions**
|
|
383
|
+
- **Incremental rollout**: Minimize risk of fleet-wide issues
|
|
384
|
+
- **Signature verification**: Prevent unauthorized firmware
|
|
385
|
+
- **Delta updates**: Reduce bandwidth (only changed files)
|
|
386
|
+
- **Rollback mechanism**: Automatic revert on boot failure
|
|
387
|
+
- **Telemetry feedback**: Monitor update success rate
|
|
388
|
+
|
|
389
|
+
### Example 2: E-commerce Recommendation System (AI/ML)
|
|
390
|
+
|
|
391
|
+
**Architecture**
|
|
392
|
+
|
|
393
|
+
1. **Data Collection**
|
|
394
|
+
- User behavior tracking (clicks, views, purchases)
|
|
395
|
+
- Product catalog and metadata
|
|
396
|
+
- Real-time event streaming (Kafka)
|
|
397
|
+
|
|
398
|
+
2. **Feature Engineering**
|
|
399
|
+
- User features: demographics, purchase history, browsing patterns
|
|
400
|
+
- Product features: category, price, ratings, popularity
|
|
401
|
+
- Context features: time of day, device, location
|
|
402
|
+
- Feature store (Redis for online, S3 for offline)
|
|
403
|
+
|
|
404
|
+
3. **Model Training**
|
|
405
|
+
- Collaborative filtering (user-item interactions)
|
|
406
|
+
- Content-based filtering (product attributes)
|
|
407
|
+
- Deep learning (neural collaborative filtering)
|
|
408
|
+
- A/B testing framework
|
|
409
|
+
|
|
410
|
+
4. **Model Serving**
|
|
411
|
+
- Real-time API (< 100ms latency)
|
|
412
|
+
- Batch predictions (daily email campaigns)
|
|
413
|
+
- Personalized ranking
|
|
414
|
+
- Fallback to popularity-based recommendations
|
|
415
|
+
|
|
416
|
+
**Implementation**
|
|
417
|
+
```python
|
|
418
|
+
# Recommendation service
|
|
419
|
+
class RecommendationService:
|
|
420
|
+
def __init__(self, feature_store, model_registry):
|
|
421
|
+
self.feature_store = feature_store
|
|
422
|
+
self.model = model_registry.get_model('recommendation', version='latest')
|
|
423
|
+
|
|
424
|
+
async def get_recommendations(
|
|
425
|
+
self,
|
|
426
|
+
user_id: str,
|
|
427
|
+
context: dict,
|
|
428
|
+
num_items: int = 10
|
|
429
|
+
) -> List[str]:
|
|
430
|
+
# Get user features from feature store
|
|
431
|
+
user_features = await self.feature_store.get_features(
|
|
432
|
+
entity_id=user_id,
|
|
433
|
+
feature_names=['age', 'gender', 'purchase_history', 'browsing_history']
|
|
434
|
+
)
|
|
435
|
+
|
|
436
|
+
# Get candidate products
|
|
437
|
+
candidates = await self.get_candidate_products(user_id, context)
|
|
438
|
+
|
|
439
|
+
# Score candidates
|
|
440
|
+
scores = await self.model.predict({
|
|
441
|
+
'user_features': user_features,
|
|
442
|
+
'product_features': [c.features for c in candidates],
|
|
443
|
+
'context': context
|
|
444
|
+
})
|
|
445
|
+
|
|
446
|
+
# Rank and return top N
|
|
447
|
+
ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)
|
|
448
|
+
return [product.id for product, score in ranked[:num_items]]
|
|
449
|
+
```
|
|
450
|
+
|
|
451
|
+
### Example 3: Supply Chain Blockchain
|
|
452
|
+
|
|
453
|
+
**Use Case**: Track pharmaceutical products from manufacturer to patient
|
|
454
|
+
|
|
455
|
+
**Architecture**
|
|
456
|
+
|
|
457
|
+
1. **Blockchain Network**
|
|
458
|
+
- Hyperledger Fabric (permissioned blockchain)
|
|
459
|
+
- Participants: manufacturers, distributors, pharmacies, regulators
|
|
460
|
+
- Channels for privacy (manufacturer ↔ distributor separate from distributor ↔ pharmacy)
|
|
461
|
+
|
|
462
|
+
2. **Smart Contracts (Chaincode)**
|
|
463
|
+
- Product registration
|
|
464
|
+
- Ownership transfer
|
|
465
|
+
- Temperature monitoring (cold chain)
|
|
466
|
+
- Authenticity verification
|
|
467
|
+
|
|
468
|
+
3. **Off-Chain Storage**
|
|
469
|
+
- IPFS for product images and documents
|
|
470
|
+
- Traditional database for query optimization
|
|
471
|
+
- Blockchain stores only hashes and critical data
|
|
472
|
+
|
|
473
|
+
4. **Integration Layer**
|
|
474
|
+
- REST API for legacy systems
|
|
475
|
+
- Event listeners for real-time notifications
|
|
476
|
+
- Mobile app for scanning and verification
|
|
477
|
+
|
|
478
|
+
**Benefits**
|
|
479
|
+
- Immutable audit trail
|
|
480
|
+
- Counterfeit prevention
|
|
481
|
+
- Regulatory compliance
|
|
482
|
+
- Supply chain transparency
|
|
483
|
+
|
|
484
|
+
---
|
|
485
|
+
|
|
486
|
+
## Understanding
|
|
487
|
+
|
|
488
|
+
### When to Use Industry-Specific Architectures
|
|
489
|
+
|
|
490
|
+
**IoT Architecture**
|
|
491
|
+
- ✅ Use when: Massive device fleets, real-time data, edge processing needed
|
|
492
|
+
- ❌ Avoid when: Simple client-server sufficient, no device management needed
|
|
493
|
+
|
|
494
|
+
**AI/ML Architecture**
|
|
495
|
+
- ✅ Use when: Data-driven decisions, personalization, prediction needed
|
|
496
|
+
- ❌ Avoid when: Rule-based logic sufficient, insufficient training data
|
|
497
|
+
|
|
498
|
+
**Blockchain Architecture**
|
|
499
|
+
- ✅ Use when: Multi-party trust needed, immutability required, decentralization valued
|
|
500
|
+
- ❌ Avoid when: Single authority acceptable, high throughput critical (>10k TPS)
|
|
501
|
+
|
|
502
|
+
**Edge Computing**
|
|
503
|
+
- ✅ Use when: Low latency critical, bandwidth limited, offline operation needed
|
|
504
|
+
- ❌ Avoid when: Cloud latency acceptable, always-connected, centralized processing preferred
|
|
505
|
+
|
|
506
|
+
### Trade-offs
|
|
507
|
+
|
|
508
|
+
| Architecture | Pros | Cons |
|
|
509
|
+
|--------------|------|------|
|
|
510
|
+
| **IoT** | Scalability, real-time data | Complexity, security challenges |
|
|
511
|
+
| **AI/ML** | Automation, personalization | Data requirements, model drift |
|
|
512
|
+
| **Blockchain** | Trust, immutability | Low throughput, high cost |
|
|
513
|
+
| **Edge** | Low latency, offline capability | Distributed complexity, limited resources |
|
|
514
|
+
|
|
515
|
+
### Best Practices
|
|
516
|
+
|
|
517
|
+
**IoT**
|
|
518
|
+
- Implement device authentication and encryption
|
|
519
|
+
- Use MQTT QoS levels appropriately (0, 1, 2)
|
|
520
|
+
- Design for intermittent connectivity
|
|
521
|
+
- Implement device shadow for state management
|
|
522
|
+
- Plan for firmware updates from day one
|
|
523
|
+
|
|
524
|
+
**AI/ML**
|
|
525
|
+
- Version all data, features, and models
|
|
526
|
+
- Monitor for model drift and bias
|
|
527
|
+
- Implement A/B testing for model changes
|
|
528
|
+
- Use feature stores for consistency
|
|
529
|
+
- Plan for model retraining pipeline
|
|
530
|
+
|
|
531
|
+
**Blockchain**
|
|
532
|
+
- Minimize on-chain data (use hashes)
|
|
533
|
+
- Optimize gas usage (for public blockchains)
|
|
534
|
+
- Implement proper key management
|
|
535
|
+
- Audit smart contracts thoroughly
|
|
536
|
+
- Consider off-chain scaling solutions (Layer 2)
|
|
537
|
+
|
|
538
|
+
**Edge Computing**
|
|
539
|
+
- Design for graceful degradation
|
|
540
|
+
- Implement local caching strategies
|
|
541
|
+
- Use delta sync for bandwidth efficiency
|
|
542
|
+
- Monitor edge node health
|
|
543
|
+
- Plan for remote management and updates
|
|
544
|
+
|
|
545
|
+
---
|
|
546
|
+
|
|
547
|
+
## References
|
|
548
|
+
|
|
549
|
+
- **IoT**: AWS IoT Core, Azure IoT Hub, Google Cloud IoT
|
|
550
|
+
- **AI/ML**: MLflow, Kubeflow, SageMaker, Vertex AI
|
|
551
|
+
- **Blockchain**: Hyperledger Fabric, Ethereum, Solidity documentation
|
|
552
|
+
- **Edge**: AWS Greengrass, Azure IoT Edge, KubeEdge
|
|
553
|
+
- **Standards**: ISO/IEC 30141 (IoT Reference Architecture)
|
|
554
|
+
|