Doug Klugh

𝗛𝗼𝘄 𝘁𝗼 𝗱𝗼 𝗺𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗽𝗿𝗼𝗽𝗲𝗿𝗹𝘆? 𝗦𝗲𝗹𝗳-𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗱 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 (𝗦𝗖𝗦) is a software architecture approach that prioritizes the decentralization of applications into independent systems, each with its domain logic, UI, and data storage. Unlike Microservices, smaller services focused solely on business logic, SCS are larger and encompass a broader scope within a specific domain. SCS are systems that represent 𝗮𝘂𝘁𝗼𝗻𝗼𝗺𝗼𝘂𝘀 𝘄𝗲𝗯 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻𝘀, which include web UI, business logic and database, and it might have a service API. A single team usually owns them. The main 𝗮𝗱𝘃𝗮𝗻𝘁𝗮𝗴𝗲𝘀 of such systems are: 𝟭. 𝗔𝘂𝘁𝗼𝗻𝗼𝗺𝘆 - Each SCS operates independently with its database, business logic, and user interface. 𝟮. 𝗗𝗼𝗺𝗮𝗶𝗻-𝗮𝗹𝗶𝗴𝗻𝗲𝗱 - SCS is structured around specific business domains, ensuring each unit represents a coherent and meaningful set of functionalities. 𝟯. 𝗗𝗲𝗰𝗲𝗻𝘁𝗿𝗮𝗹𝗶𝘇𝗲𝗱 𝗗𝗮𝘁𝗮 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 - Individual databases per SCS ensure data consistency within its boundary, reducing cross-service dependencies. 𝟰. 𝗧𝗲𝗰𝗵𝗻𝗼𝗹𝗼𝗴𝘆 𝗗𝗶𝘃𝗲𝗿𝘀𝗶𝘁𝘆 - Allows for different technology stacks to be used across other SCS, suiting the specific needs of each domain. 𝟱. 𝗘𝘅𝗽𝗹𝗶𝗰𝗶𝘁𝗹𝘆 𝗣𝘂𝗯𝗹𝗶𝘀𝗵𝗲𝗱 𝗜𝗻𝘁𝗲𝗿𝗳𝗮𝗰𝗲 - Well-defined interfaces for interactions with other systems, maintaining a clear contract while preserving encapsulation. 𝟲. 𝗜𝗻𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝘁 𝗗𝗲𝗽𝗹𝗼𝘆𝗮𝗯𝗶𝗹𝗶𝘁𝘆 - Each SCS can be deployed, scaled, and updated independently without affecting other systems. Such systems go well along with 𝗗𝗼𝗺𝗮𝗶𝗻-𝗱𝗿𝗶𝘃𝗲𝗻 𝗗𝗲𝘀𝗶𝗴𝗻 (𝗗𝗗𝗗). The first step in creating such systems is domain analysis, which can be conducted by identifying bounded contexts that align with specific business domains. Each bounded context is then encapsulated within an SCS, which comprises its own data management, business logic, and user interface, ensuring each system is autonomous yet able to interact with others through well-defined APIs when necessary. Why Self-contained Systems (SCS) has the 𝗲𝗱𝗴𝗲 𝗼𝘃𝗲𝗿 𝗺𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀: 🔹 𝗕𝗿𝗼𝗮𝗱𝗲𝗿 𝘀𝗰𝗼𝗽𝗲: SCS has a broader scope encompassing the UI, business logic, and data storage within a bounded context 🔹 𝗥𝗲𝗱𝘂𝗰𝗲𝗱 𝗢𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗖𝗼𝗺𝗽𝗹𝗲𝘅𝗶𝘁𝘆: Microservices can lead to a high level of operational complexity due to the management of many smaller, interdependent services, while SCS is more significant and more autonomous. 🔹 𝗗𝗮𝘁𝗮 𝗖𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝘆: SCS manages their data, leading to better data consistency within each system, while Microservices often rely on a shared data store. Check the full link in the comments. #technology #softwareengineering #softwaredesign #techworldwithmilan #microservices

34

⚠️ Attention, software engineers and managers! Your career path is changing. AI isn't about replacing you; it's elevating your role to an orchestrator of intelligent solutions. The industry is shifting, and managers must lead teams to integrate AI effectively into the end-to-end software development lifecycle. To stay ahead, you need to upskill. Focus on practical skills like context engineering, understanding AI system architecture, and integrating AI APIs. The future belongs to those who embrace and master these new tools! #AI #AIinSoftware #SoftwareEngineering #CareerDevelopment #FutureofWork #Upskilling

9

Mastering Clean Architecture Principles and Application This episode provides an in-depth analysis of Clean Architecture, a software design philosophy that prioritizes the separation of business logic from external technical concerns. By organizing systems into concentric layers, this framework ensures that core rules remain independent of volatile elements like databases, user interfaces, and third-party tools. Central to this approach is the Dependency Rule, which mandates that source code dependencies must only point inward toward higher-level policies. The texts examine how this structure enhances testability and maintainability across various technology stacks while also warning against the risks of over-engineering simple projects. Ultimately, the materials present Clean Architecture as a strategic economic choice that reduces the long-term cost of change in complex software environments. #cleanarchitecture #softwareengineering #softwaredevelopment #codingtutorial #systemdesign #programming #solidprinciples #backend #softwarearchitecture #developerguide #techstrategy #cleancode https://lnkd.in/g2tqh3dr

2

I was reflecting on the EOL for Maven 3.8. As Maven 4 moves into Beta with RC4 available, what does that mean for your CICD pipelines pinned to “latest”? ‼️Danger. Pay attention to your tooling. Pin to a version or family, e.g., 3, 3.9, 3.9.11. I recall APIs builds failing on the 3.9.0 release with the retirement of very old utilities auto injected on the class path for backward compatibility. 💥 One pipeline passes and the next fails as caches are refreshed for “latest”. Once between builds in the same hour.

7

A great resource for those looking to keep architecture diagrams inline with their source code in their Git Repo. I, personally, have liked both Mermaid Chart and PlantUML. But, looking to evaluate others mentioned in this list. It also helps tremendously if the tool has IDE plugins with Visual Studio Code or IntelliJ.

19

Great explanations of different types of files under .claude folder. — Minor updates: Custom commands have been merged into skills. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way.

5

1 Comment

Architecture Complexity Should Reflect Problem Scope Good architecture is an exercise in proportionality. Systems work best when their complexity matches the scope, size, and operating context of the problem they are meant to solve. Some problems justify advanced distribution and resilience. Others benefit most from simplicity, clarity, and ease of change. Neither approach is inherently better. Value comes from alignment. --- A Practical Way to Find the Right Level of Complexity Instead of starting with: “What is the most robust architecture we can build?” Start with: “What problem are we solving, and at what scale?” The checklist below is intended to guide that reasoning. --- Problem Scope Alignment Checklist 1) Define the primary use case What is the system primarily responsible for? - Internal workflow - Customer-facing interaction - Core transactional capability Clear scope prevents accidental over-design. --- 2) Estimate concurrent usage How many users or systems interact with it at the same time? - Dozens - Hundreds - Thousands or more Concurrency is often a stronger architectural driver than total users. --- 3) Understand change frequency How often does the system evolve? - Infrequently - Periodically - Continuously Systems that change often benefit from simpler designs and clearer boundaries. --- 4) Clarify operational expectations What level of availability and responsiveness is expected? - Best effort - Business hours - Always-on Explicit expectations lead to intentional tradeoffs. --- 5) Match design to team capability Who will build and operate the system? - A small product team - Shared ownership across teams - A dedicated platform or operations team Architecture should amplify the team’s strengths, not compensate for gaps. --- Closing Principle Architecture is a tool for solving problems, not a statement of ambition. The best designs are those that fit the problem they serve. This framing keeps architecture grounded in: - problem size - real usage - team reality - long-term maintainability And helps avoid unnecessary complexity introduced without clear need.

8

2 Comments

My OpenClaw agents can now use Claude Code without an API key. No credentials in config files. No secrets to leak. No API key anywhere on the agent side. I built Conduit — an open-source orchestration layer that sits between your agent framework and Claude Code. It uses your existing Claude Code login to expose the full agent runtime (file I/O, bash, MCP servers) as a REST API on your local network. Your agents talk HTTP. Claude Code does the work. Your credentials never leave your machine. OpenClaw (agent) → REST → Conduit → Claude Code CLI → your codebase Conduit is the firewall. The agents on one side never see the credentials on the other. Here's the kicker: I run OpenClaw primarily on local Ollama models. Ollama handles the reasoning and orchestration. When agents need to actually touch code — read files, run commands, modify a codebase — they delegate to Claude Code through Conduit. Local brains, cloud muscle, zero leaked credentials. If you're building autonomous agents that need more than text completion — if they need to actually DO things in a codebase — you need Claude Code's tool runtime. But you can't hand your API key to every agent you build. Conduit solves that. Five backend dependencies. Zero configuration. → Spawn multiple concurrent Claude Code sessions across projects → Real-time streaming via WebSocket and SSE → Cost and token tracking per session → Deny-rule guardrails to block destructive operations → Full audit trail of every tool decision Open source. Apache 2.0. #OpenClaw #ClaudeCode #OpenSource #AI #Ollama #BuildInPublic

25

21 Comments