从JPA和MyBatis的开发过程来看其设计思路区别就有点大了
MyBatis的工具主要都是面向现有表结构，然后才有对象的设计方式，其最佳实践环境应是在有专门的DBA帮助完成表设计，然后依据表设计来构建业务代码
而JPA的思路是，我先有对象，然后仅仅是分析对象之间的关系，并持久化对象，其两者的思路不一致
二者都可以应用DDD做设计，但因为分工原因，会导致其DBA的设计思路是按着最少冗余设计，而开发时候只能迁就其设计思路
而对象设计者很可能是对象的实现者，这时候，将持久化的过程交给一套方法或者规则来完成，能最大化匹配其实现业务代码的思路
做起开发发现浑身不对劲就很难受了
需求变本来就是常态，为什么品控部门必须要有确定的文档才能进行需求开发
难道开发面对变更，测试就不需要面对变更吗？
测试参与到开发来，而不应该是测试只管根据文档测试其他都不用管
目标难道不是交付合格的软件么，没有写好的文档就不能交付了么，无非就是撕逼的时候为了个责任划分而吵吵吵吗
一点都感受不到大家是为了交付或者是有共同的目标，就单纯的是为了工作而工作，能做出什么像样的东西么
还有，需求日期这种东西，不应该是开发人员预估个时间，然后才能是对外宣传的呢，怎么能说是随口说出去，然后层层下压呢
最少也应该在开发给出一个不算太靠谱的时间之后进行压缩吧
一个稳定的软件不应该是要留足开发空间么，而非只是为了收钱而交付啊
就算是为了满足生存的需求，那生存本身不应该是压缩成本吗？没有做好亏一段时间的准备，难道创业是不需要成本的？
这些看起来不像是问题而像是控诉的话题，应该就是所谓的问题了吧
这些问题问了自己好久，得不到答案
通过JPA（Hibernate）在MySQL环境下自动建表要注意，JPA的默认字段长度为255，而如果数据库中存在索引不能超过768bytes的限制，则需要考虑自己手工维护表
限制来源于JPA或默认新建一个记录序号的表，此表的主键为Varchar(255)，且程序员无法修改，只要编码长度是超过三字节编码，则建表失败
可以通过SpringData/Hibernate自动调用classpath下特定的sql文件特性绕过
但如果抛弃了由hibernate做表维护而转为程序员手工维护表关系则不如采用mybatis方案更为直接
hibernate自动建表时候，是没法设置在哪个schame下或者哪个catalog下建表，如果DB的其他schame有同名表，则建表会失败
此限制来源于Hibernate做数据库元数据查询时候只使用了table字段，且我无法找到可以让查询元数据时候指定schame+table联合确定table是否存在的办法
此限制的场景会在Junit测试时候如果想做schame隔离是无法做到的
一并发现此问题的还有activiti的自动建表也是
以下配置均是以CentOS7来进行
[mysqld0]
basedir = /usr
character_set_server = utf8
collation_server = utf8_unicode_ci
datadir = /opt/data0
default_storage_engine = InnoDB
default_time_zone = '+8:00'
event_scheduler = 1
init_connect = 'set names utf8;'
lower_case_table_names = 1
memlock = 0
pid_file = /opt/data0/mysql.pid
port = 3306
skip_external_locking = 1
socket = /opt/data0/mysql.sock
tmpdir = /dev/shm
user = mysql
general_log = 0
general_log_file = /opt/data0/general_query.log
log_output = FILE
log_error = /opt/data0/mysqld.log
log_warnings = 2
log_queries_not_using_indexes = 1
log_slow_admin_statements = 1
log_slow_verbosity = query_plan
long_query_time = 1
min_examined_row_limit = 100
slow_query_log = 1
slow_query_log_file = /opt/data0/slow_query.log
gtid_strict_mode = 1
transaction_isolation = READ-COMMITTED
innodb_data_home_dir = /opt/data0
innodb_log_group_home_dir = /opt/data0
innodb_undo_directory = /opt/data0
binlog_cache_size = 4M
binlog_checksum = crc32
binlog_format = row
expire_logs_days = 30
log_bin = /opt/data0/mysql-bin
max_binlog_cache_size = 128M
max_binlog_size = 1G
sync_binlog = 1
max_relay_log_size = 1G
relay_log = /opt/data0/relay-bin
relay_log_index = /opt/data0/relay-bin.index
relay_log_info_file = relay-log.info
relay_log_purge = 1
relay_log_recovery = 1
sync_relay_log = 10000
mysql_install_db --datadir=/opt/data0 --user=mysql --force --defaults-file=/etc/my.cnf.d/3306.cnf
mysql_install_db --datadir=/opt/data1 --user=mysql --force --defaults-file=/etc/my.cnf.d/3307.cnf
mkdir /etc/systemd/system/[email protected]
#
# /etc/systemd/system/[email protected]
#
[Unit]
Description=Multi-Instance MariaDB Service
After=network.target
After=syslog.target
[Install]
WantedBy=multi-user.target
[Service]
User=mysql
Group=mysql
Type=forking
# true is needed for the ExecStartPre
PermissionsStartOnly=true
ExecStartPre=/usr/bin/mkdir -p /opt/data%i
ExecStartPre=/usr/bin/chown mysql:mysql /opt/data%i -R
ExecStart=/usr/bin/mysqld_multi start %i
ExecStop=/usr/bin/mysqld_multi stop %i
LimitNOFILE=102400
Restart=on-failure
RestartPreventExitStatus=1
PrivateTmp=true
systemctl start mariadb@{0,1}
mysqladmin -hlocalhost -P3306 --protocol=tcp password abc
mysqladmin -hlocalhost -P3307 --protocol=tcp password abc
mysql -P3306 --protocol=tcp -uroot -pabc
mysql -P3307 --protocol=tcp -uroot -pabc
本质上锁是如下的一个数据结构
struct waitList{
*ExecuteNode root;
*ExecuteNode next;
}
每当一个进程/线程开始执行的时候，cpu会读取要操作的内存结构，其head中有一个字段是CPU保证当前过程不能发生软中断（基于语言虚拟机有相似的过程），当CPU发现这个字段置为1/true时候，CPU应要忽略其他请求，直到把该位置恢复为false，然后随机唤醒一个进程/线程（ExecuteNode）
基于以上事实在调度过程中，就能发现和我们在Java中使用锁的表现一致，但CPU不能保证其他进程/线程不能修改该标志位（系统或者语言调度器保证）
所以我写这篇文章的目的很简单，为了给各位写代码的新手带来一点不同的视角
代码不过是业务的表示，当你把代码看作一门语言（这里语言不是指java/C这些编码语言的意思，而是普适意义上的language）的时候，我们，作为编码人员，更多的是像是陈述事实一样，将业务陈述，然后通过代码落地。
在新手中，经常有这么几个疑问
1. 这么写有什么用
2. 明明我一个函数就可以把所有工作做完，为什么要拆开来
3. 这个工具屌不屌
4. 这个语言如何如何
不知道各位呆过几个公司，每家公司给人的感觉都是不一样的。提几个点让大家想一想
1. 有问题能不能找到确定的一个人能解决确定的一类问题
2. 出了事情，背锅是平摊锅还是说加权锅，还是看老板心情分
3. 简单点，如果电脑坏了要换，上报后多久能搞定
4. 工作的成果是否能够量化
让我们来换到代码的视角来看这个问题
1. 出了bug能否容易精确定位在什么类
2. 出错了，整个系统的其他部分是否依旧稳定
3. 某个部件如果因为市场因素全部重做，重做的成本是低是高
可能换到编码视角，各位一定能够简单的提出一些熟悉的概念，比如鲁棒性，比如重构，etc。但是不知道各位有没有做过思考，亦即这些概念套用到非编码视角的时候也是通用的，更或者说，这概念都是从其他行业或者领域移植到软件开发领域，毕竟软件开发到今天真正普及也就四十年？
信息安全中经常需要验证一条信息，其做法是，定义一个函数f，f作用于信息得到一条简短的信息，即f(g(x)，c) == f(h(x),c) == F 其中，g(x)是发送端的信息，h(x)是接收端信息，c是双方约定的一个信息，F是计算的结果,如果经过f作用后，得到的结果是相同，那么就可以认为，这条信息是真实的。
原理上这东西很简单，也非常实用，那么对应到不是信息安全领域中呢。
举个例子：
现在我经常性面对的问题是：
举个例子：
那么这时候谁对谁错，作为一个负责人，这时候就要想到这么一个事情，这个事情的目标是什么：
那么上面的对错就容易判断了，如果a提出的1,2,3,4,5不满足A1,A2,A3,A4，一律是要砍掉，只保留能够满足A1,A2,A3,A4的设计
对应出来我们就得到了类似的和信息安全领域的结果即
f(1,2,3,4,5) == A1,A2,A3,A4
如此我们总能够简单的验证我们的工作成果，而不是陷入无止境的扯皮中
通过对软件开发进行划分层级，可以帮助我们开发过程中渐进式开发
比如我要关注业务代码的时候，就纯粹的业务思维，如果我是底层的开发，我只需要关注计算机领域的知识
我在开发中观察到，大部分新手或者开发了很久的人，在写代码的时候，过早的关注到细节问题，比如写开发票的时候就开始关注到发票数据库字段长度，就直接陷进了细节中，具体对外表现出来就是业务实现统统一个函数打包，甚至还有全局变量等等
渐进式的分层开发有助于我们专注于一件事件，只有专注了，那么开发中错误才能减少
那么四流合一就很明白了，四流的内容能够完全反映出整个供应链链条的运作
即四流可以与一条供应链等价
为了实现四流合一，又提出了三库的说法
以上是构成现代供应链的几个基础要素
到了这一步则系统的概设完成
对照直营故事来细化
1. 询价单
2. 供应商目录
3. 商品目录
4. 采购合同
5. 销售合同
6. 采购订单
7. 销售订单
8. 发票
9. 通知
对照垫资代采故事细化
1. 资金提供商目录
2. 项目信息
3. 垫资代采合同
4. 与客户确认单据
按照此思路逐项分析，直至形成一个业务需求文档