Separation of Concerns

In computer science, separation of concerns (SoC) is a design principle for separating a computer program into distinct sections. Each section addresses a separate concern, a set of information that affects the code of a computer program. A concern can be as general as “the details of the hardware for an application”, or as specific as “the name of which class to instantiate”. A program that embodies SoC well is called a modular program. Modularity, and hence separation of concerns, is achieved by encapsulating information inside a section of code that has a well-defined interface. Encapsulation is a means of information hiding.[2] Layered designs in information systems are another embodiment of separation of concerns (e.g., presentation layer, business logic layer, data access layer, persistence layer).

Separation of concerns results in more degrees of freedom for some aspect of the program’s design, deployment, or usage. Common among these is increased freedom for simplification and maintenance of code. When concerns are well-separated, there are more opportunities for module upgrade, reuse, and independent development. Hiding the implementation details of modules behind an interface enables improving or modifying a single concern’s section of code without having to know the details of other sections and without having to make corresponding changes to those other sections. Modules can also expose different versions of an interface, which increases the freedom to upgrade a complex system in piecemeal fashion without interim loss of functionality

Separation of concerns is a form of abstraction. As with most abstractions, separating concerns means adding additional code interfaces, generally creating more code to be executed. So despite the many benefits of well-separated concerns, there is often an associated execution penalty.

Design by contract (DbC)

Design by contract (DbC), also known as contract programming, programming by contract and design-by-contract programming, is an approach for designing software.

It prescribes that software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, postconditions and invariants. These specifications are referred to as “contracts”, in accordance with a conceptual metaphor with the conditions and obligations of business contracts.

The DbC approach assumes all client components that invoke an operation on a server component will meet the preconditions specified as required for that operation.

通常对DB执行的增，删，改，查（CRUD）都是针对的系统的实体对象。如通过数据访问层获取数据，然后通过数据传输对象DTO传给表现层。或者，用户需要更新数据，通过DTO对象将数据传给Model，然后通过数据访问层写回数据库，系统中的所有交互都是和数据查询和存储有关，可以认为是数据驱动（Data-Driven）的，如下图：

对于一些比较简单的系统，使用这种CRUD的设计方式能够满足要求。特别是通过一些代码生成工具及ORM等能够非常方便快速的实现功能。

但是传统的CRUD方法有一些问题：

• 使用同一个对象实体来进行数据库读写可能会太粗糙，大多数情况下，比如编辑的时候可能只需要更新个别字段，但是却需要将整个对象都穿进去，有些字段其实是不需要更新的。在查询的时候在表现层可能只需要个别字段，但是需要查询和返回整个实体对象。
• 使用同一实体对象对同一数据进行读写操作的时候，可能会遇到资源竞争的情况，经常要处理的锁的问题，在写入数据的时候，需要加锁。读取数据的时候需要判断是否允许脏读。这样使得系统的逻辑性和复杂性增加，并且会对系统吞吐量的增长会产生影响。
• 同步的，直接与数据库进行交互在大数据量同时访问的情况下可能会影响性能和响应性，并且可能会产生性能瓶颈。
• 由于同一实体对象都会在读写操作中用到，所以对于安全和权限的管理会变得比较复杂。

命令查询分离（Command Query Separation）

Bertrand Meyer 在 1988 年出版的《Object-Oriented Software Construction》一书中提出了“命令查询分离”的概念，这本书被认为是早期面向对象领域最具影响力的著作之一。

Meyer 说，The fundamental idea is that we should divide an object’s methods into two sharply separated categories:

• Queries: Return a result and do not change the observable state of the system (are free of side effects).
• Commands: Change the state of a system but do not return a value.

CQS is a simple concept: it is about methods within the same object being either queries or commands. Each method either returns state or mutates state, but not both. Even a single repository pattern object can comply with CQS.

CQS can be considered a foundational principle for CQRS.

CQS 其实也体现/遵循了单一职责原则（Single Resposibility Principle）。

不过，仍然会有一些特例逃逸于这个原则之外。比如，正如 Martin Fowler 所说的，从一个队列或栈弹出一个元素时，不仅改变了这个队列或栈，还返回了一个元素。

Meyer correctly says that you can avoid having this method, but it is a useful idiom. So I prefer to follow this principle when I can, but I’m prepared to break it to get my pop.

Multitier Architecture

In software engineering, multitier architecture (often referred to as n-tier architecture) or multilayer architecture is a client–server architecture in which presentation, application processing and data management functions are physically separated. The most widespread use of multitier architecture is the three-tier architecture.

N-tier application architecture provides a model by which developers can create flexible and reusable applications. By segregating an application into tiers, developers acquire the option of modifying or adding a specific layer, instead of reworking the entire application. A three-tier architecture is typically composed of a presentation tier, a logic tier, and a data tier.

Tier vs. layer

While the concepts of layer and tier are often used interchangeably, one fairly common point of view is that there is indeed a difference. This view holds that a layer is a logical structuring mechanism for the elements that make up the software solution, while a tier is a physical structuring mechanism for the system infrastructure.

The Contacts app on your phone, for example, is a three-layer application, but a single-tier application, because all three layers run on your phone.

The difference is important, because layers can’t offer the same benefits as tiers.

Three-tier Architecture

Three-tier architecture is a well-established software application architecture that organizes applications into three logical and physical computing tiers: the presentation tier, or user interface; the application tier, where data is processed; and the data tier, where the data associated with the application is stored and managed.

The chief benefit of three-tier architecture is that because each tier runs on its own infrastructure, each tier can be developed simultaneously by a separate development team, and can be updated or scaled as needed without impacting the other tiers.

Domain-driven design (DDD)

Domain-driven design (DDD) is the concept that the structure and language of software code (class names, class methods, class variables) should match the business domain. So that the designed system is high conhesion and low coupling

For example, if a software processes loan applications, it might have classes such as LoanApplication and Customer, and methods such as AcceptOffer and Withdraw.

My Case

# via SMB
$ time rsync -aPXcv --delete test-rsync /Volumes/SSDPool2/rsync
# via ssh
$ time rsync -avPX --delete -e 'ssh -p 34270' ../myBlogV2 root@192.168.18.93:/mnt/SSDPool2/DS/rsync

# via rsync protocol
$ rsync -aPXz --delete myBlogV2 rsync://192.168.18.93/sw_rsync/
# sync from ubuntu to truenas
$ rsync -az -vvvv node_exporter-1.0.1.linux-amd64.tar.gz rsync://192.168.18.93/sw_rsync/

System Level

By default, the maximum number of files that Mac OS X can open is set to 12,288 and the maximum number of files a given process can open is 10,240.

You can check these with:

$ sysctl kern.maxfiles
$ sysctl kern.maxfilesperproc

You can increase the limits (at your own risk) with:

$ sysctl -w kern.maxfiles=20480
$ sysctl -w kern.maxfilesperproc=18000

To make the change permanent, use sudo to put your settings in /etc/sysctl.conf (which you may have to create), like this:

kern.maxfiles=20480
kern.maxfilesperproc=18000

Note: In OS X 10.10 or lower, you can add setting in /etc/launchd.conf like limit maxfiles and it will override whatever you put here.