These notes represent my understanding of code patterns. The concepts are from Patterns of Enterprise Application Architecture by Martin Fowler with contributions from others.
My current understanding of code patterns is a pattern describes the general structure of a specific class or module, and possibly its subclasses or submodules. My sense is that when Rails defines a group of classes as ActiveRecord, it uses the term to describe the general purpose of these classes, however, I think Rails ActiveRecord probably contains multiple coding patterns.
A good learning tool when reading code is to determine the pattern for each class or module.
I have been learning Ruby on Rails(“Rails”) as well as Ruby. What’s amazing about Rails it’s a One Person Framework used by micro-business software firms as well as large entities such as Shopify, Github, and 37Signals.
Rails provides a framework making it easier to build data-driven websites, however, my data conversion engine that my app will rely on will be built with Ruby not Rails. Rails relies on the Convention Over Configuation principle that makes creating a Rails app easier. The COC principle is based on code patterns such as Active Record, Model-View-Controller, etc.
Patterns describe a recurring problem; then describes a consistent way to solve the problem through code. Layering is used in system design to separate code in logical components in a complicated software system or app.
Fowler separates coding into three basic layers: presentation logic, domain logic, and data source logic.
Presentation logic layer handles the interaction between the server and the user.
Domain logic refers to the business logic. Fowler divides domain logic into three patterns: transaction script, domain model, and table module.
Data source is about the communication between various systems that handles various tasks of your application. In my case, it’s my app and Quickbooks, my app and SQLite, messaging systems, etc.)