Alex Fedorov

### Using Domain Objects in practice On the other hand, domain objects, by default will hide all access to the data from the outside and hide all the database related...

Maybe it makes sense for me to try to make an ad-hoc implementation (in a branch or separate shard) for these 2 patterns and try to write a simple application...

@sdogruyol On the question of practicality/reality, I was writing applications using such patterns for quite a while (1.5 years), and it feels much better than your usual Web MVC, active...

Not only AR fails, but the whole Web-version of MVC is one big AntiPattern. Original MVC was about programming User Interfaces, without any business logic inside. And Model-View-Controller triples were...

General overview of architecture I prefer looks like this: ![digraph](http://gravizo.com/g? digraph G { {WebUI; RESTfulAPI; DatabaseStorage; ExternalPaymentService} -> "Business Domain Code" [label=plugin] }) `plugin` means that application code itself doesn't...

It should be clear, that there are very distinct boundaries between business domain logic and non-domain logic. These boundaries have their code dependencies inverted, as opposed to their runtime dependencies....

Needless to say, that plugins should not depend on existence of other plugins and should not be using the interfaces of other plugins.

Hi @spalladino What is the current behavior, when someone operates on the table without auto-increment and supplies `id` explicitly? My assumption, that it should just work, at least for postgres...

[Here](https://github.com/waterlink/postgres_adapter.cr/blob/master/src/postgres_adapter.cr#L128) update functionality removes `primary_field` too. I believe that is okay. So it looks like the difference in the behavior have to be on the adapter's side (`create(fields)` function). Maybe...

This actually will still not work. Since `JSON.mapping` expects mapped fields to be in `@`, but they are in `@typed_fields[][]` at the moment.