Skip to content

Core

The Machc Project focuses on building modular, scalable, and maintainable applications using the principles of Clean Architecture. The Machc Core serves as the foundation of the project, featuring essential components such as Entities, Use Cases, and Interface Adapters. These layers are designed to ensure separation of concerns, testability, and adaptability, enabling the development of robust Python-based systems.

Project Structure

Entities

Entities encapsulate enterprise-wide business rules and serve as the foundation of the application’s core logic. They represent the most high-level and immutable concepts of the system, such as business objects or key domain models, and are designed to remain independent of any changes outside the core logic.

Use Cases

The Use Cases layer contains application-specific business rules and orchestrates the flow of data to and from the entities, implementing the application's goals. Each use case directs the entities to use their business rules to fulfill specific requirements, ensuring clean separation between core logic and external systems.

See: Core Lib (Entities and Interactors)

Adapters

The Interface Adapters layer converts data between the internal format used by entities and use cases and the external format required by external systems (e.g., databases, web services, or the frontend).

See: Adapters Project

Commons Library

The Commons Library provides shared utilities and tools that simplify the overall development process. These libraries ensure consistency and accelerate development by adding reusable components that abstract complex functionalities.

See: Commons

SOLID Principles for Architecture

Clean Architecture benefits significantly from applying the SOLID Principles, ensuring that both code and architecture remain maintainable, flexible, and scalable.

  1. SRP: Single Responsibility Principle: Every component (e.g., module, class, or function) should have only one reason to change, promoting separation of concerns.
    • Applied to architecture: Each layer (Entities, Use Cases, Interface Adapters) has a single well-defined responsibility.
  2. OCP: Open-Closed Principle: Software components should be open for extension but closed for modification.
    • Applied to architecture: New features can be added without modifying core logic, ensuring stability and predictability.
  3. LSP: Liskov Substitution Principle: Derived classes must be substitutable for their base classes.
    • Applied to architecture: Implementations of adapters should conform to the interface contracts defined in the core.
  4. ISP: Interface Segregation Principle: Interfaces should define only the methods needed by the consumer to avoid unnecessary dependencies.
    • Applied to architecture: Interfaces for databases or external APIs should be concise and avoid complexity bleeding into the core.
  5. DIP: Dependency Inversion Principle: High-level modules should not depend on low-level modules. Both should depend on abstractions.
    • Applied to architecture: Infrastructure and frameworks should depend on the core business logic defined in the Entities and Use Cases.

As recommended in Clean Architecture: A Craftsman's Guide to Software Structure and Design1, these principles should extend not only to code-level design but also to the broader architectural viewpoint.

References

  1. Clean Architecture: A Craftsman's Guide to Software Structure and Design ↩

https://www.free-Counters.org