HN Books @HNBooksMonth

Fowler is a great resource for this:

https://martinfowler.com/articles/enterprisePatterns.html

More specifically this book: https://www.amazon.com/Patterns-Enterprise-Application-Archi...

(None of these are affiliate links)

https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

https://www.amazon.com/Clean-Architecture-Craftsmans-Softwar...

https://www.amazon.com/Patterns-Enterprise-Application-Archi...

https://www.amazon.com/Refactoring-Improving-Existing-Addiso...

https://www.amazon.com/Code-Complete-Practical-Handbook-Cons...

https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...

https://www.amazon.com/Mythical-Man-Month-Software-Engineeri...

And just because it’s asked at every interview.

https://www.amazon.com/Design-Patterns-Object-Oriented-Addis...

I’m focused on AWS these days, but a lot of these principals are universal.

https://d1.awsstatic.com/whitepapers/architecture/AWS_Well-A...

Wrong. Business logic is part of the model.

Source:

http://www.amazon.com/Patterns-Enterprise-Application-Archit...

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93cont...

http://stackoverflow.com/a/4415941/61624

http://programmers.stackexchange.com/a/165446/56945

⬐ ryeguy

Not necessarily, putting business logic in the models as opposed to service classes is a recipe for disaster in any decent sized application. People are realizing this, even in the rails community, and are moving away from it. Putting business logic in the model is not a scalable solution and generally leads to god objects.

Unless your definition of model is the business logic area of your application. Saying that business logic goes in the model, in terms of the general rails sense, is the bad route.

⬐ tieTYT

I'm not saying put it in models I'm saying it's part of the Model of MVC. If you've got a class called FooBarService that takes a model and executes business logic on it, that FooBarService can still be part of the Model of MVC.

If, on the other hand, FooBarService has a handler for a MouseEvent - something that should be done in the Controller - and business logic in it too, now you're violating MVC because your Model and Controller aren't separated.

BTW, IMO to name something FooBarService or BazQuxService is a code smell. "Service" carries no significance. Same goes for "Manager" or "Logic" or whatever generic thing you end up using. Any code could be in there. I have to look inside it to see. It also gives you an excuse to make those file huge because anything could be in there. It's a violation of the Single Responsibility Principle.

Hah, yes, I'm a Java programmer.

⬐ asdasf

>Unless your definition of model is the business logic area of your application.

Yes, that is the definition of the model in MVC.

⬐ dreamfactory

I'd say the model is a black box for business data and logic yes. So I'd consider the M and O from the article to be the model - encapsulated data + behaviour. IMO the E part of the article maps to the controller layer (in the web version of MVC).

I think there are two areas of confusion on the topic:

1. Web MVC isn't the same as the traditional MVC pattern as seen in apps and described in patterns literature. In the web version all communication between model and view is mediated through the controller layer and there is no direct control between them) - many web developers are only aware of this variant.

2. Rails popularised web MVC and used ActiveRecord which meant that models were essentially table wrappers and this pushed business object logic into the controller.

For me the next step after MVC is PAC - http://en.wikipedia.org/wiki/Presentation%E2%80%93abstractio... (which I think is pretty much the same thing as HMVC). Adding that extra dimension of multiple self-contained triads keeps the controller layer from becoming a single unwieldy mess of spaghetti spread across the whole web layer. (Ironically I suppose it does introduce a concept of events binding them which may bring it full circle to some ideas in the article.)

The ORM layer does give you ACID or rather it doesn't take it away. It does joins and transactions. It's just an abstraction. I suggest you read up on PoEEA [1] as I don't think you understand what an ORM is properly or you've had experience of some rubbish ones like ActiveRecord or Django's ORM. See Unit of Work pattern, identity map etc to start with and work back.

NHibernate, SQLAlchemy, Hibernate are where you need to look and compare.

The ORM does a few joins where a performance gain is possible but we avoid them though as they are expensive on IO and transfer.

Most of our tables match the UI 1:1 and we populate these from the domain model when it is mutated or when we can afford it to be done (either directly or via message queues). Effectively they are materialized views which are updated when data changes or before it is required. Google CQRS.

I'm not suggesting NoSQL - just caution when using RDBMS features. I'm not an advocate of NoSQL.

[1] http://www.amazon.co.uk/Enterprise-Application-Architecture-...

⬐ bunderbunder

One can't just say "joins are expensive on IO and transfer"; you have to specify exactly what kind of join you're talking about and how it's being used. The way an INNER JOIN will influences how rows are retrieved is completely different from how an OUTER JOIN or CROSS JOIN will.

In all those cases, the devil remains in the details. For example if you're just looking to add one or two columns to the result set, an INNER or OUTER JOIN usually reduces the amount of data that has to be shoved through the pipe. That's because you avoid transmitting the keys that are needed to join the data in-app. On the other hand, if you're joining a small number of larger values to a table with lots of rows, perhaps the join duplicates those values enough to really bulk up the result set. But it's effectively impossible to know whether that will be the case without measuring the performance for a couple different options.

Here's an alternative consideration: ORMs tend to encourage a style of coding wherein every column in the table is always grabbed all the time, regardless of how much of that information is actually needed for the task at hand. This is done in order to be able to generate full-fledged objects like the ORM wants to, and to reduce the amount of custom mapping that needs to be maintained. Now if you're looking for a needless waste of bandwidth, there's a needless waste of bandwidth.

If you're consistently having performance problems on joins, it's likely that the real culprit is poor configuration of keys and indexes. Or if you're not watching how the ORM chooses to join the data too closely, perhaps you've got some N+1 queries sneaking in there.

This one is supposed to be good: Patterns of Enterprise Application Architecture, by Martin Fowler http://www.amazon.com/Patterns-Enterprise-Application-Archit...

I am trying to do the same thing as you, and I recently ordered this text based on a recommendation from a mentor.

⬐ voytekg

Thanks for that! Haven't come across this book, so will definitely check it out.

Did your mentor have any recommendations on the actual infrastructure setup as well? (e.g., servers, networks, data center locations)