# Fractal
> Fractal is a scaffolding toolkit for building SOLID logic for your Python applications.
[![PyPI Version][pypi-image]][pypi-url]
[![Build Status][build-image]][build-url]
[![Code Coverage][coverage-image]][coverage-url]
[![Code Quality][quality-image]][quality-url]
<!-- Badges -->
[pypi-image]: https://img.shields.io/pypi/v/fractal-toolkit
[pypi-url]: https://pypi.org/project/fractal-toolkit/
[build-image]: https://github.com/douwevandermeij/fractal/actions/workflows/build.yml/badge.svg
[build-url]: https://github.com/douwevandermeij/fractal/actions/workflows/build.yml
[coverage-image]: https://codecov.io/gh/douwevandermeij/fractal/branch/master/graph/badge.svg
[coverage-url]: https://codecov.io/gh/douwevandermeij/fractal
[quality-image]: https://api.codeclimate.com/v1/badges/55adbc041d119d371ef7/maintainability
[quality-url]: https://codeclimate.com/github/douwevandermeij/fractal
## Installation
```sh
pip install fractal-toolkit
```
## Usage
* Fractal can be used inside large Python applications to isolate certain (logical related) behaviour from the rest of
the application.
* Fractal is ideal for refactoring large applications into smaller parts
* Fractal applications by design are microservices
* Just wrap the app in an HTTP framework (like FastAPI, see contrib module) and expose with Docker
* Other usages apart from HTTP (and Docker) are also possible
* Like subscribing to a data stream or pub/sub channel
## Architecture
Applications that use Fractal can be built in many ways, including a non-SOLID architecture.
The Fractal toolkit tries to make it easier to go for the SOLID approach.
To start a Fractal project, the first class to make derives from `fractal.Fractal`.
It should provide a `fractal.core.utils.settings.Settings` object and a
`fractal.core.utils.application_context.ApplicationContext` object, which should also be derived from.
The `Settings` class provides all static configuration for the application; it's the place where environment variables
are loaded. The class creates a singleton object.
The `Context` class provides the dynamic configuration of the application, using the `Settings` object.
In the `Context` all dependencies will be injected.
### Hexagonal Architecture (ports and adapters)
In Hexagonal Architecture, together with Domain Driven Design principles, the core of the application, is the bounded
context containing the domain objects (entities, repositories, services, etc.) but without specific implementation
details. Just the domain logic. From now on we call the core the domain.
This is (loosely) enforced by not allowing dependencies to external packages inside the domain.
This, in turn, is the _dependency inversion principle_ of SOLID.
The repositories and services inside the domain are interfaces or abstract classes. These are known as ports.
Next to the domain there are the adapters. Each interface or port needs an adapter to function at runtime. Adapters are
allowed to depend on external packages.
At runtime, in the application `Context`, based on `Settings`, the appropriate adapter will be set for each port.
### Basic application structure
A typical application folder structure using Fractal looks like:
app/
├── adapters/
│ ├── __init__.py
│ └── products.py
├── domain/
│ ├── __init__.py
│ └── products.py
├── context.py
├── main.py
└── settings.py
With this, a fully functional Fractal application can be built having a Python interface. That is, the logic of the
application can only be reached by invoking methods on Python level.
Such Fractal applications might be used as part of larger (Python) applications to isolate or encapsulate certain
behaviour. The larger application itself can also be a Fractal application, and so on. Hence the name: Fractal.
While using Fractal as a way to have separation of concerns with separate isolated bounded contexts in Python
applications, it's also possible to wrap Fractal in a small application and expose as REST API using, for example,
FastAPI, Flask or Django. Next that application can be deployed again in a Docker environment. This makes Fractal a
perfect fit for microservices as well.
As a rule of thumb, continuing on the separation of concerns, the folder/file structure inside a Fractal application
should follow the naming of the subject (rather than the naming of the responsibilities of module).
In the example app this is denoted by `products.py` in both the `domain` folder as the `adapters` folder.
When the file is getting too big to be easily readable or maintainable, it can be converted into a package.
Within the package the files can be named by their responsibilities.
An example package folder structure:
app/
├── adapters/
│ └── products/
│ ├── __init__.py
│ ├── django.py
│ └── fastapi.py
├── domain/
│ └── products/
│ ├── __init__.py
│ ├── commands/
│ │ ├── __init__.py
│ │ └── add.py
│ └── events.py
├── context.py
├── main.py
└── settings.py
As can be seen in the example package folder structure, in the `domain` the package contains files about certain
actions or responsibilities andf in the `adapters` folder it's more about the target implementation.
Of course the target implementation file can be converted into a package again and contain files for certain
responsibilities again.
#### Example file contents
##### main.py
```python
from fractal import Fractal
from app.context import ApplicationContext
from app.settings import Settings
class ApplicationFractal(Fractal):
settings = Settings()
context = ApplicationContext()
```
##### settings.py
```python
import os
from fractal.core.utils.settings import Settings as BaseSettings
class Settings(BaseSettings):
BASE_DIR = os.path.dirname(__file__)
ROOT_DIR = os.path.dirname(os.path.dirname(BASE_DIR))
APP_NAME = os.getenv("APP_NAME", "product_system")
def load(self):
self.PRODUCT_REPOSITORY_BACKEND = os.getenv("PRODUCT_REPOSITORY_BACKEND", "")
```
##### context.py
```python
from fractal.core.utils.application_context import ApplicationContext as BaseContext
from app.settings import Settings
class ApplicationContext(BaseContext):
def load_repositories(self):
from app.domain.products import ProductRepository
if Settings().PRODUCT_REPOSITORY_BACKEND == "sql":
'''example: some sql adapter code'''
elif Settings().PRODUCT_REPOSITORY_BACKEND == "file":
'''example: some file adapter code'''
else:
from app.adapters.products import InMemoryProductRepository
self.product_repository: ProductRepository = self.install_repository(
InMemoryProductRepository(),
)
```
##### domain/products.py
```python
from abc import ABC
from dataclasses import dataclass
from fractal.core.models import Model
from fractal.core.repositories import Repository
@dataclass
class Product(Model):
id: str
name: str
class ProductRepository(Repository[Product], ABC):
pass
```
##### adapters/products.py
```python
from fractal.core.repositories.inmemory_repository_mixin import InMemoryRepositoryMixin
from app.domain.products import Product, ProductRepository
class InMemoryProductRepository(ProductRepository, InMemoryRepositoryMixin[Product]):
pass
```
## Advanced features
### Command bus pattern
A command is a container to invoke actions in the domain, from inside and outside of the domain.
A command has a one-to-one relation with a command handler.
The command handler can be seen as a single transaction, e.g., to a database.
The code in the command handler should just be doing just the things that are necessary to be inside the transaction.
Transactions can fail, so it's important to prevent side effects from happening and include only the code that needs to
go in the same transaction and thus will be rolled back as a whole in case the transaction fails.
Secondary actions that need to take place _after_ the action has been done, should be outside of scope of the command
handler.
After a command handler has been completed successfully, that is, when the transaction is persisted, an event can be
published. This event is the trigger for all secondary actions, which in turn can be commands again.
#### Example file contents
The affected files in the folder structure:
app/
└── domain/
│ └── products/
│ └── commands.py
└── context.py
##### commands.py
Without publishing events:
```python
from dataclasses import dataclass
from fractal.core.command_bus.command_handler import CommandHandler
from fractal.core.command_bus.commands import AddEntityCommand
from app.context import ApplicationContext
from app.domain.products import Product, ProductRepository
@dataclass
class AddProductCommand(AddEntityCommand[Product]):
pass
class AddProductCommandHandler(CommandHandler):
command = AddProductCommand
def __init__(
self,
product_repository: ProductRepository,
):
self.product_repository = product_repository
@staticmethod
def install(context: ApplicationContext):
context.command_bus.add_handler(
AddProductCommandHandler(
context.product_repository,
)
)
def handle(self, command: AddProductCommand):
self.product_repository.add(command.entity)
```
##### context.py
```python
from fractal.core.utils.application_context import ApplicationContext as BaseContext
class ApplicationContext(BaseContext):
...
def load_command_bus(self):
super(ApplicationContext, self).load_command_bus()
from app.domain.products.commands import AddProductCommandHandler
AddProductCommandHandler.install(self)
```
### Event publishing
When an event gets published, the `EventPublisher` will iterate over its registered projectors (`EventProjector`).
Each projector will be invoked with the event as a parameter.
Projectors can do anything:
- printing the event to the console
- populating a repository
- like an event store
- or a read optimized view
- invoking a new command
- sending the event to an external service, which may:
- invoke a new command
- send an email
Each projector should only be doing one thing.
The relation between an event and a projector is one-to-many.
**!! CAVEAT !!**
When using events, and especially when sending events to an external service, be aware that these other services might
have a dependency on the structure of the event.
Changing existing events is **dangerous**.
The best approach here is to apply the _open-closed principle_ of SOLID, open for extension, closed for modification.
Alternatively creating a new event is also possible.
#### Example file contents
The affected files in the folder structure, on top of the command bus pattern code:
app/
└── domain/
│ └── products/
│ ├── commands.py
│ └── events.py
└── context.py
##### commands.py
```python
from dataclasses import dataclass
from datetime import datetime
from fractal.core.command_bus.command_handler import CommandHandler
from fractal.core.command_bus.commands import AddEntityCommand
from fractal.core.event_sourcing.event_publisher import EventPublisher
from app.context import ApplicationContext
from app.domain.products import Product, ProductRepository
from app.domain.products.events import ProductAddedEvent
@dataclass
class AddProductCommand(AddEntityCommand[Product]):
user_id: str
class AddProductCommandHandler(CommandHandler):
command = AddProductCommand
def __init__(
self,
event_publisher: EventPublisher,
product_repository: ProductRepository,
):
self.event_publisher = event_publisher
self.product_repository = product_repository
@staticmethod
def install(context: ApplicationContext):
context.command_bus.add_handler(
AddProductCommandHandler(
context.event_publisher,
context.product_repository,
)
)
def handle(self, command: AddProductCommand):
event = ProductAddedEvent(
id=command.entity.id,
name=command.entity.name,
created_by=command.user_id,
created_on=datetime.utcnow(),
)
self.product_repository.add(command.entity)
self.event_publisher.publish_event(event)
```
##### events.py
```python
from dataclasses import dataclass
from datetime import datetime
from typing import Callable, Dict, List, Type
from fractal.core.command_bus.command import Command
from fractal.core.event_sourcing.event import (
BasicSendingEvent,
Event,
EventCommandMapper,
)
@dataclass
class ProductEvent(BasicSendingEvent):
id: str
@property
def object_id(self):
return self.id
@property
def aggregate_root_id(self):
return self.id
@dataclass
class ProductAddedEvent(ProductEvent):
name: str
created_by: str
created_on: datetime
class ProductEventCommandMapper(EventCommandMapper):
def mappers(self) -> Dict[Type[Event], List[Callable[[Event], Command]]]:
return {
# example:
# ProductAddedEvent: [
# lambda event: SomeCommand(...)
# ],
}
```
##### context.py
```python
from fractal.core.utils.application_context import ApplicationContext as BaseContext
class ApplicationContext(BaseContext):
...
def load_event_projectors(self):
from fractal.core.event_sourcing.projectors.command_bus_projector import (
CommandBusProjector,
)
from app.domain.products.events import ProductEventCommandMapper
self.command_bus_projector = CommandBusProjector(
lambda: self.command_bus,
[
ProductEventCommandMapper(),
],
)
from fractal.core.event_sourcing.projectors.print_projector import (
PrintEventProjector,
)
return [
self.command_bus_projector,
PrintEventProjector(),
]
```
### Eventual consistency
TODO
### Event sourcing
TODO
### Specification pattern
TODO
### FastAPI + Docker
TODO
Request contract, together with URI parameters and authentication token payload can be processed by the application
by using the command bus. The command can ingest the separate variables and/or domain objects (entities).
Response contract might be different from the domain object that is affected by the request.
### Authentication
TODO
Raw data
{
"_id": null,
"home_page": "https://github.com/douwevandermeij/fractal",
"name": "fractal-toolkit",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.8",
"maintainer_email": null,
"keywords": null,
"author": "Douwe van der Meij",
"author_email": "douwe@karibu-online.nl",
"download_url": "https://files.pythonhosted.org/packages/ff/77/bc368b5453c451de22e39176ec23b0f7e2c6c0e5d120ae2c236e3dd4c7fa/fractal_toolkit-4.1.3.tar.gz",
"platform": null,
"description": "# Fractal\n\n> Fractal is a scaffolding toolkit for building SOLID logic for your Python applications.\n\n[![PyPI Version][pypi-image]][pypi-url]\n[![Build Status][build-image]][build-url]\n[![Code Coverage][coverage-image]][coverage-url]\n[![Code Quality][quality-image]][quality-url]\n\n<!-- Badges -->\n\n[pypi-image]: https://img.shields.io/pypi/v/fractal-toolkit\n[pypi-url]: https://pypi.org/project/fractal-toolkit/\n[build-image]: https://github.com/douwevandermeij/fractal/actions/workflows/build.yml/badge.svg\n[build-url]: https://github.com/douwevandermeij/fractal/actions/workflows/build.yml\n[coverage-image]: https://codecov.io/gh/douwevandermeij/fractal/branch/master/graph/badge.svg\n[coverage-url]: https://codecov.io/gh/douwevandermeij/fractal\n[quality-image]: https://api.codeclimate.com/v1/badges/55adbc041d119d371ef7/maintainability\n[quality-url]: https://codeclimate.com/github/douwevandermeij/fractal\n\n## Installation\n\n```sh\npip install fractal-toolkit\n```\n\n## Usage\n\n* Fractal can be used inside large Python applications to isolate certain (logical related) behaviour from the rest of\nthe application.\n* Fractal is ideal for refactoring large applications into smaller parts\n* Fractal applications by design are microservices\n * Just wrap the app in an HTTP framework (like FastAPI, see contrib module) and expose with Docker\n * Other usages apart from HTTP (and Docker) are also possible\n * Like subscribing to a data stream or pub/sub channel\n\n## Architecture\n\nApplications that use Fractal can be built in many ways, including a non-SOLID architecture.\nThe Fractal toolkit tries to make it easier to go for the SOLID approach.\n\nTo start a Fractal project, the first class to make derives from `fractal.Fractal`.\nIt should provide a `fractal.core.utils.settings.Settings` object and a\n`fractal.core.utils.application_context.ApplicationContext` object, which should also be derived from.\n\nThe `Settings` class provides all static configuration for the application; it's the place where environment variables\nare loaded. The class creates a singleton object.\n\nThe `Context` class provides the dynamic configuration of the application, using the `Settings` object.\nIn the `Context` all dependencies will be injected.\n\n### Hexagonal Architecture (ports and adapters)\n\nIn Hexagonal Architecture, together with Domain Driven Design principles, the core of the application, is the bounded\ncontext containing the domain objects (entities, repositories, services, etc.) but without specific implementation\ndetails. Just the domain logic. From now on we call the core the domain.\n\nThis is (loosely) enforced by not allowing dependencies to external packages inside the domain.\nThis, in turn, is the _dependency inversion principle_ of SOLID.\n\nThe repositories and services inside the domain are interfaces or abstract classes. These are known as ports.\n\nNext to the domain there are the adapters. Each interface or port needs an adapter to function at runtime. Adapters are\nallowed to depend on external packages.\n\nAt runtime, in the application `Context`, based on `Settings`, the appropriate adapter will be set for each port.\n\n### Basic application structure\n\nA typical application folder structure using Fractal looks like:\n\n app/\n \u251c\u2500\u2500 adapters/\n \u2502 \u251c\u2500\u2500 __init__.py\n \u2502 \u2514\u2500\u2500 products.py\n \u251c\u2500\u2500 domain/\n \u2502 \u251c\u2500\u2500 __init__.py\n \u2502 \u2514\u2500\u2500 products.py\n \u251c\u2500\u2500 context.py\n \u251c\u2500\u2500 main.py\n \u2514\u2500\u2500 settings.py\n\nWith this, a fully functional Fractal application can be built having a Python interface. That is, the logic of the\napplication can only be reached by invoking methods on Python level.\n\nSuch Fractal applications might be used as part of larger (Python) applications to isolate or encapsulate certain\nbehaviour. The larger application itself can also be a Fractal application, and so on. Hence the name: Fractal.\n\nWhile using Fractal as a way to have separation of concerns with separate isolated bounded contexts in Python\napplications, it's also possible to wrap Fractal in a small application and expose as REST API using, for example,\nFastAPI, Flask or Django. Next that application can be deployed again in a Docker environment. This makes Fractal a\nperfect fit for microservices as well.\n\nAs a rule of thumb, continuing on the separation of concerns, the folder/file structure inside a Fractal application\nshould follow the naming of the subject (rather than the naming of the responsibilities of module).\nIn the example app this is denoted by `products.py` in both the `domain` folder as the `adapters` folder.\nWhen the file is getting too big to be easily readable or maintainable, it can be converted into a package.\nWithin the package the files can be named by their responsibilities.\n\nAn example package folder structure:\n\n app/\n \u251c\u2500\u2500 adapters/\n \u2502 \u2514\u2500\u2500 products/\n \u2502 \u251c\u2500\u2500 __init__.py\n \u2502 \u251c\u2500\u2500 django.py\n \u2502 \u2514\u2500\u2500 fastapi.py\n \u251c\u2500\u2500 domain/\n \u2502 \u2514\u2500\u2500 products/\n \u2502 \u251c\u2500\u2500 __init__.py\n \u2502 \u251c\u2500\u2500 commands/\n \u2502 \u2502 \u251c\u2500\u2500 __init__.py\n \u2502 \u2502 \u2514\u2500\u2500 add.py\n \u2502 \u2514\u2500\u2500 events.py\n \u251c\u2500\u2500 context.py\n \u251c\u2500\u2500 main.py\n \u2514\u2500\u2500 settings.py\n\nAs can be seen in the example package folder structure, in the `domain` the package contains files about certain\nactions or responsibilities andf in the `adapters` folder it's more about the target implementation.\nOf course the target implementation file can be converted into a package again and contain files for certain\nresponsibilities again.\n\n#### Example file contents\n\n##### main.py\n\n```python\nfrom fractal import Fractal\n\nfrom app.context import ApplicationContext\nfrom app.settings import Settings\n\n\nclass ApplicationFractal(Fractal):\n settings = Settings()\n context = ApplicationContext()\n```\n\n##### settings.py\n\n```python\nimport os\n\nfrom fractal.core.utils.settings import Settings as BaseSettings\n\n\nclass Settings(BaseSettings):\n BASE_DIR = os.path.dirname(__file__)\n ROOT_DIR = os.path.dirname(os.path.dirname(BASE_DIR))\n APP_NAME = os.getenv(\"APP_NAME\", \"product_system\")\n\n def load(self):\n self.PRODUCT_REPOSITORY_BACKEND = os.getenv(\"PRODUCT_REPOSITORY_BACKEND\", \"\")\n```\n\n##### context.py\n\n```python\nfrom fractal.core.utils.application_context import ApplicationContext as BaseContext\n\nfrom app.settings import Settings\n\n\nclass ApplicationContext(BaseContext):\n def load_repositories(self):\n from app.domain.products import ProductRepository\n\n if Settings().PRODUCT_REPOSITORY_BACKEND == \"sql\":\n '''example: some sql adapter code'''\n elif Settings().PRODUCT_REPOSITORY_BACKEND == \"file\":\n '''example: some file adapter code'''\n else:\n from app.adapters.products import InMemoryProductRepository\n\n self.product_repository: ProductRepository = self.install_repository(\n InMemoryProductRepository(),\n )\n```\n\n##### domain/products.py\n\n```python\nfrom abc import ABC\nfrom dataclasses import dataclass\n\nfrom fractal.core.models import Model\nfrom fractal.core.repositories import Repository\n\n\n@dataclass\nclass Product(Model):\n id: str\n name: str\n\n\nclass ProductRepository(Repository[Product], ABC):\n pass\n```\n\n##### adapters/products.py\n\n```python\nfrom fractal.core.repositories.inmemory_repository_mixin import InMemoryRepositoryMixin\n\nfrom app.domain.products import Product, ProductRepository\n\n\nclass InMemoryProductRepository(ProductRepository, InMemoryRepositoryMixin[Product]):\n pass\n```\n\n## Advanced features\n\n### Command bus pattern\n\nA command is a container to invoke actions in the domain, from inside and outside of the domain.\nA command has a one-to-one relation with a command handler.\nThe command handler can be seen as a single transaction, e.g., to a database.\n\nThe code in the command handler should just be doing just the things that are necessary to be inside the transaction.\nTransactions can fail, so it's important to prevent side effects from happening and include only the code that needs to\ngo in the same transaction and thus will be rolled back as a whole in case the transaction fails.\n\nSecondary actions that need to take place _after_ the action has been done, should be outside of scope of the command\nhandler.\n\nAfter a command handler has been completed successfully, that is, when the transaction is persisted, an event can be\npublished. This event is the trigger for all secondary actions, which in turn can be commands again.\n\n#### Example file contents\n\nThe affected files in the folder structure:\n\n app/\n \u2514\u2500\u2500 domain/\n \u2502 \u2514\u2500\u2500 products/\n \u2502 \u2514\u2500\u2500 commands.py\n \u2514\u2500\u2500 context.py\n\n##### commands.py\n\nWithout publishing events:\n\n```python\nfrom dataclasses import dataclass\n\nfrom fractal.core.command_bus.command_handler import CommandHandler\nfrom fractal.core.command_bus.commands import AddEntityCommand\n\nfrom app.context import ApplicationContext\nfrom app.domain.products import Product, ProductRepository\n\n\n@dataclass\nclass AddProductCommand(AddEntityCommand[Product]):\n pass\n\n\nclass AddProductCommandHandler(CommandHandler):\n command = AddProductCommand\n\n def __init__(\n self,\n product_repository: ProductRepository,\n ):\n self.product_repository = product_repository\n\n @staticmethod\n def install(context: ApplicationContext):\n context.command_bus.add_handler(\n AddProductCommandHandler(\n context.product_repository,\n )\n )\n\n def handle(self, command: AddProductCommand):\n self.product_repository.add(command.entity)\n```\n\n##### context.py\n\n```python\nfrom fractal.core.utils.application_context import ApplicationContext as BaseContext\n\n\nclass ApplicationContext(BaseContext):\n\n ...\n\n def load_command_bus(self):\n super(ApplicationContext, self).load_command_bus()\n\n from app.domain.products.commands import AddProductCommandHandler\n\n AddProductCommandHandler.install(self)\n```\n\n### Event publishing\n\nWhen an event gets published, the `EventPublisher` will iterate over its registered projectors (`EventProjector`).\nEach projector will be invoked with the event as a parameter.\n\nProjectors can do anything:\n- printing the event to the console\n- populating a repository\n - like an event store\n - or a read optimized view\n- invoking a new command\n- sending the event to an external service, which may:\n - invoke a new command\n - send an email\n\nEach projector should only be doing one thing.\nThe relation between an event and a projector is one-to-many.\n\n**!! CAVEAT !!**\n\nWhen using events, and especially when sending events to an external service, be aware that these other services might\nhave a dependency on the structure of the event.\nChanging existing events is **dangerous**.\nThe best approach here is to apply the _open-closed principle_ of SOLID, open for extension, closed for modification.\nAlternatively creating a new event is also possible.\n\n#### Example file contents\n\nThe affected files in the folder structure, on top of the command bus pattern code:\n\n app/\n \u2514\u2500\u2500 domain/\n \u2502 \u2514\u2500\u2500 products/\n \u2502 \u251c\u2500\u2500 commands.py\n \u2502 \u2514\u2500\u2500 events.py\n \u2514\u2500\u2500 context.py\n\n##### commands.py\n\n```python\nfrom dataclasses import dataclass\nfrom datetime import datetime\n\nfrom fractal.core.command_bus.command_handler import CommandHandler\nfrom fractal.core.command_bus.commands import AddEntityCommand\nfrom fractal.core.event_sourcing.event_publisher import EventPublisher\n\nfrom app.context import ApplicationContext\nfrom app.domain.products import Product, ProductRepository\nfrom app.domain.products.events import ProductAddedEvent\n\n\n@dataclass\nclass AddProductCommand(AddEntityCommand[Product]):\n user_id: str\n\n\nclass AddProductCommandHandler(CommandHandler):\n command = AddProductCommand\n\n def __init__(\n self,\n event_publisher: EventPublisher,\n product_repository: ProductRepository,\n ):\n self.event_publisher = event_publisher\n self.product_repository = product_repository\n\n @staticmethod\n def install(context: ApplicationContext):\n context.command_bus.add_handler(\n AddProductCommandHandler(\n context.event_publisher,\n context.product_repository,\n )\n )\n\n def handle(self, command: AddProductCommand):\n event = ProductAddedEvent(\n id=command.entity.id,\n name=command.entity.name,\n created_by=command.user_id,\n created_on=datetime.utcnow(),\n )\n self.product_repository.add(command.entity)\n self.event_publisher.publish_event(event)\n```\n\n##### events.py\n\n```python\nfrom dataclasses import dataclass\nfrom datetime import datetime\nfrom typing import Callable, Dict, List, Type\n\nfrom fractal.core.command_bus.command import Command\nfrom fractal.core.event_sourcing.event import (\n BasicSendingEvent,\n Event,\n EventCommandMapper,\n)\n\n\n@dataclass\nclass ProductEvent(BasicSendingEvent):\n id: str\n\n @property\n def object_id(self):\n return self.id\n\n @property\n def aggregate_root_id(self):\n return self.id\n\n\n@dataclass\nclass ProductAddedEvent(ProductEvent):\n name: str\n created_by: str\n created_on: datetime\n\n\nclass ProductEventCommandMapper(EventCommandMapper):\n def mappers(self) -> Dict[Type[Event], List[Callable[[Event], Command]]]:\n return {\n # example:\n # ProductAddedEvent: [\n # lambda event: SomeCommand(...)\n # ],\n }\n```\n\n##### context.py\n\n```python\nfrom fractal.core.utils.application_context import ApplicationContext as BaseContext\n\n\nclass ApplicationContext(BaseContext):\n\n ...\n\n def load_event_projectors(self):\n from fractal.core.event_sourcing.projectors.command_bus_projector import (\n CommandBusProjector,\n )\n\n from app.domain.products.events import ProductEventCommandMapper\n\n self.command_bus_projector = CommandBusProjector(\n lambda: self.command_bus,\n [\n ProductEventCommandMapper(),\n ],\n )\n\n from fractal.core.event_sourcing.projectors.print_projector import (\n PrintEventProjector,\n )\n\n return [\n self.command_bus_projector,\n PrintEventProjector(),\n ]\n```\n\n### Eventual consistency\n\nTODO\n\n### Event sourcing\n\nTODO\n\n### Specification pattern\n\nTODO\n\n### FastAPI + Docker\n\nTODO\n\nRequest contract, together with URI parameters and authentication token payload can be processed by the application\nby using the command bus. The command can ingest the separate variables and/or domain objects (entities).\n\nResponse contract might be different from the domain object that is affected by the request.\n\n### Authentication\n\nTODO\n",
"bugtrack_url": null,
"license": null,
"summary": "Fractal is a scaffolding toolkit for building SOLID logic for your Python applications.",
"version": "4.1.3",
"project_urls": {
"Homepage": "https://github.com/douwevandermeij/fractal"
},
"split_keywords": [],
"urls": [
{
"comment_text": null,
"digests": {
"blake2b_256": "591961dab90ece0e8cb2b729d0e6168254303bc8fb66f7344c60ef2d809488dc",
"md5": "5aec7dbed84a94a691a2ff18217e7965",
"sha256": "aaff4bebd7454da24925f2fa4e247d1da87c2851cf999bd9294550699558686b"
},
"downloads": -1,
"filename": "fractal_toolkit-4.1.3-py3-none-any.whl",
"has_sig": false,
"md5_digest": "5aec7dbed84a94a691a2ff18217e7965",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.8",
"size": 43686,
"upload_time": "2023-10-15T14:49:50",
"upload_time_iso_8601": "2023-10-15T14:49:50.796724Z",
"url": "https://files.pythonhosted.org/packages/59/19/61dab90ece0e8cb2b729d0e6168254303bc8fb66f7344c60ef2d809488dc/fractal_toolkit-4.1.3-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": null,
"digests": {
"blake2b_256": "ff77bc368b5453c451de22e39176ec23b0f7e2c6c0e5d120ae2c236e3dd4c7fa",
"md5": "c1296c1fb64bc2108c26ec61c274c9b2",
"sha256": "debea3f852c4ab9f2041f8334b28b99fcb7746f075712bc111e8e202d746c6e5"
},
"downloads": -1,
"filename": "fractal_toolkit-4.1.3.tar.gz",
"has_sig": false,
"md5_digest": "c1296c1fb64bc2108c26ec61c274c9b2",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.8",
"size": 39376,
"upload_time": "2023-10-15T14:49:53",
"upload_time_iso_8601": "2023-10-15T14:49:53.093051Z",
"url": "https://files.pythonhosted.org/packages/ff/77/bc368b5453c451de22e39176ec23b0f7e2c6c0e5d120ae2c236e3dd4c7fa/fractal_toolkit-4.1.3.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2023-10-15 14:49:53",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "douwevandermeij",
"github_project": "fractal",
"travis_ci": false,
"coveralls": true,
"github_actions": true,
"tox": true,
"lcname": "fractal-toolkit"
}
JSON
