4 ms·

> Would that mediator be another app? Yes! It is an app that might not even have any model classes. But it will contain business logic. And it will probably s

by hbrn 4y ago

> Would that mediator be another app? Yes! It is an app that might not even have any model classes. But it will contain business logic. And it will probably speak domain language, which is great. If you're lucky, those two other apps will become pluggable. You will probably never replace them, but separation of concerns is always nice. The downside of course is that you will have 3 apps instead of 1. That's the balance you have to maintain.

cjohnson318 4y ago
So, the way I understand it, job/services.py and load/services.py depend on mediator/mediator.py which depends on job/models.py and load/models.py, instead of job/services.py ultimately using load/services.py, and vice versa. Thanks so much!
- hbrn 4y ago
  This is good enough to break circular dependencies between individual modules, but keep in mind that circular dependencies between the apps remain (e.g. job depends on mediator, mediator depends on job). I usually prefer to resolve those too. If job is small enough, all the orchestration of jobs should happen through mediator (same for load). If it's not plausible, then job can emit signals which mediator subscribes to. A good place to start is to give a more descriptive name to the mediator. Sure, it mediates between the two, but it probably does that to implement some business process. Can you name it after that process?
  - cjohnson318 4y ago
    > ...all the orchestration of jobs should happen through mediator (same for load) So, in a smaller app, when a request comes into job/views.py or load/views.py then we immediately start working with JobLoadMediator to handle business logic between the two? I was just going to focus on specific tasks between job and load. I'll probably look into signals; I haven't used those in several years and as I recall, it felt hacky. > give a more descriptive name to the mediator When a Job is deleted, it needs to delete associated Loads. And the states of the Loads will affect the state of the Job. That's the main cycle I'm looking at right now.
    - hbrn 4y ago
      > when a request comes into job/views.py or load/views.py then we immediately start working with JobLoadMediator to handle business logic between the two? In my world, mediator.views and job.views would likely have different audiences. mediator.views is for business domain (e.g. your API). Though name would not be mediator, it would be something domain-specific. job.views could be for more low-level internal tooling (e.g. analytics/monitoring). Or it could be empty, if job is just dumb data object that has a lifecycle but doesn't require public API. > When a Job is deleted, it needs to delete associated Loads. And the states of the Loads will affect the state of the Job If you want to keep them apart, signals is the right (though not the easiest) answer. job owns (depends on) loads, and subscribes to loads signals. load doesn't know anything about job (ignore the fact that job is referenced in load.models as foreign key, that's just limitations of SQL DDL). The easiest is a subtle dependency: load can access job through foreign key, job can access loads through related_name. Circular dependency is still there, but it is resolved at runtime. This will start to cause pain when application grows, but is fine at small scale. Though again, I'd probably merge those apps: if you can't reason about load without job, and can't reason about job without load, there's very little benefit in keeping them separate. It might make you feel more organized, but the if the code is lying about your mental model, this is false organization.
      - cjohnson318 4y ago
        > mediator.views is for business domain (e.g. your API) > job.views could be for more low-level internal tooling That's very interesting. I'm mostly following the architecture from: https://phalt.github.io/django-api-domains/styleguide/ https://phalt.github.io/django-api-domains/styleguide/ I knew this was going to be a large project, about 19 apps, supporting a trucking and inventory web/mobile app, and I wanted a sane/organized way to deal with all of the models and relations. Do you know of some blog posts or books that go into the way you normally organize things? > if you can't reason about load without job, and can't reason about job without load There is a lot of interaction between all of the parts of the app, but particularly between Jobs, Loads, Inventory, Stages, and Drivers. In the future I might start with one app, and then add another if I absolutely have to.
  - cjohnson318 4y ago
    Holy bovine. This finally worked. I've been working around the clock on this for two days now. Thanks again stranger!
    - funkydata 4y ago
      Also, do not forget to integrate with Sentry [https://sentry.io/ https://sentry.io/] or something that does the same thing. It will also keep you sane.

by hbrn 4y ago

cjohnson318 4y ago

So, the way I understand it, job/services.py and load/services.py depend on mediator/mediator.py which depends on job/models.py and load/models.py, instead of job/services.py ultimately using load/services.py, and vice versa. Thanks so much!

hbrn 4y ago
This is good enough to break circular dependencies between individual modules, but keep in mind that circular dependencies between the apps remain (e.g. job depends on mediator, mediator depends on job). I usually prefer to resolve those too. If job is small enough, all the orchestration of jobs should happen through mediator (same for load). If it's not plausible, then job can emit signals which mediator subscribes to. A good place to start is to give a more descriptive name to the mediator. Sure, it mediates between the two, but it probably does that to implement some business process. Can you name it after that process?
- cjohnson318 4y ago
  > ...all the orchestration of jobs should happen through mediator (same for load) So, in a smaller app, when a request comes into job/views.py or load/views.py then we immediately start working with JobLoadMediator to handle business logic between the two? I was just going to focus on specific tasks between job and load. I'll probably look into signals; I haven't used those in several years and as I recall, it felt hacky. > give a more descriptive name to the mediator When a Job is deleted, it needs to delete associated Loads. And the states of the Loads will affect the state of the Job. That's the main cycle I'm looking at right now.
  - hbrn 4y ago
    > when a request comes into job/views.py or load/views.py then we immediately start working with JobLoadMediator to handle business logic between the two? In my world, mediator.views and job.views would likely have different audiences. mediator.views is for business domain (e.g. your API). Though name would not be mediator, it would be something domain-specific. job.views could be for more low-level internal tooling (e.g. analytics/monitoring). Or it could be empty, if job is just dumb data object that has a lifecycle but doesn't require public API. > When a Job is deleted, it needs to delete associated Loads. And the states of the Loads will affect the state of the Job If you want to keep them apart, signals is the right (though not the easiest) answer. job owns (depends on) loads, and subscribes to loads signals. load doesn't know anything about job (ignore the fact that job is referenced in load.models as foreign key, that's just limitations of SQL DDL). The easiest is a subtle dependency: load can access job through foreign key, job can access loads through related_name. Circular dependency is still there, but it is resolved at runtime. This will start to cause pain when application grows, but is fine at small scale. Though again, I'd probably merge those apps: if you can't reason about load without job, and can't reason about job without load, there's very little benefit in keeping them separate. It might make you feel more organized, but the if the code is lying about your mental model, this is false organization.
    - cjohnson318 4y ago
      > mediator.views is for business domain (e.g. your API) > job.views could be for more low-level internal tooling That's very interesting. I'm mostly following the architecture from: https://phalt.github.io/django-api-domains/styleguide/ https://phalt.github.io/django-api-domains/styleguide/ I knew this was going to be a large project, about 19 apps, supporting a trucking and inventory web/mobile app, and I wanted a sane/organized way to deal with all of the models and relations. Do you know of some blog posts or books that go into the way you normally organize things? > if you can't reason about load without job, and can't reason about job without load There is a lot of interaction between all of the parts of the app, but particularly between Jobs, Loads, Inventory, Stages, and Drivers. In the future I might start with one app, and then add another if I absolutely have to.
- cjohnson318 4y ago
  Holy bovine. This finally worked. I've been working around the clock on this for two days now. Thanks again stranger!
  - funkydata 4y ago
    Also, do not forget to integrate with Sentry [https://sentry.io/ https://sentry.io/] or something that does the same thing. It will also keep you sane.