In Martin Fowler's article you linked, he says of the Anemic Domain Model:
At first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have.
The catch comes when you look at the behavior, and you realize that
there is hardly any behavior on these objects, making them little more
than bags of getters and setters. Indeed often these models come with
design rules that say that you are not to put any domain logic in the
the domain objects.
The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together. What's worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about.
However, having said that, he also says this:
Putting behavior into the domain objects should not contradict the solid approach of using layering to separate domain logic from such things as persistence and presentation responsibilities. The logic that should be in a domain object is domain logic - validations, calculations, business rules - whatever you like to call it.
This is where View Models come in.
View Models contain two things:
- All of the data that is required to execute a view, and
- Any logic that is required to render the view, but which can be pushed back into the ViewModel, rather than cluttering the view.
If the ViewModel does not contain any logic, then it is could properly be called an Anemic Model. But it is not an anemic model of the domain. While it might contain data from domain objects, the ViewModel object's sole reason for existence is to separate domain logic from presentation, just as Fowler observes.
The resulting arrangement makes it much simpler to focus on layout and user interaction in the View, without being concerned about how that interaction might pollute the domain objects and their logic, or vice versa. It is the layer of separation that Fowler describes.
See Also
The View Model Pattern
Isn't MVC Anti-OOP?
Direct answer to your question might not do you much good but it boils down to using triggers if your databases are on the same server, or using your account creation logic to remotely trigger creation on the other application as well. However, I'd like to stress that syncing data can lead to likelier data losses unless some robustness mechanisms are in place (scheduled synchronization, repeated attempts at triggering the creation, etc).
Almost always a better approach would be to maintain a single source of truth. However, this does not avoid complexity either.
Here are some approaches you could go for:
Assumptions
Given the formulation of your question, I'm going to assume all of the user accounts should be replicated on both applications. E.g. there are no app-specific user accounts.
Approach #1: same database server, separate database
A straightforward approach would be creating a third database that contains shared data for both applications, in this case the user accounts. You could reference the database from your usual queries, since it's all on the same server. (If we assume you're using Django, on your User model you'll need to specify the database. To do this, you'll have to look into replacing the user model for the default auth system which is more of a hassle than I'd like to admit)
Approach #2: separate authentication service
You could maintain a separate application (a service, to be precise) which would be queried over a secured connection to prove the authentication claims. This would introduce significant complexities, as you'd have to authenticate your sessions manually, which is somewhat tedious as you might be used to it being automated by popular Python frameworks.
A more worthwhile option might be looking into third party authentication services such as https://auth0.com. You can find Python documentation here
Disclaimer: I am not affiliated nor experienced with Auth0 services, they're just given as an example.
Best Answer
From the documentation, I am assuming that by "most templating systems", they are referring primarily to server-side templates which get rendered into a view. I feel comfortable making this assumption due to a later statement explaining why angular is different: "... the template ... is compiled on the browser. The compilation step produces a live view." And also because other client-side MVVM / MVC / MVP (aka MV*) libraries offer a similar two-way binding.
For server-side templating, it is not usual for it to be a "live view", because the view is actually rendered on the server instead of the browser. This essentially makes server-side binding one-way. The client must submit changes. Then the server recomputes binding values and renders a new view from those values. I'm not only talking about traditional form-based pages. This applies equally to frameworks which asynchronously load view partials which are computed on the server.
In angular, the model and controller live alongside the view. So, when the user changes a view value, it is pretty immediately changed on the model, and the controller can react to that change... recalculating computed values, loading related data, etc. But again, other client-side libraries are capable of this.
I would say that the terminology is not great here, because angular internally has one-way and two-way binding on directives. This confuses the issue a bit. But for directives, it more amounts to whether the model property is exposed as read-only (one-way) or read/write (two-way). (There's slightly more to it than that, but that's the gist of it.)
Update
So it seems to me that this page is more targeted at something like ReactJS, although it could apply to server-side techs as well. Here is an interesting (biased) article further discussing one-way vs two-way binding. (React is one-way.)