上全套 UML 工具，然后又多出来了 UML 工具购买成本、学习成本、重构成本。

工具选型或者过程选型，需要综合成本和收益综合考虑，百人以下的团队，数据库字段描述文档、给前端的标准文档（临时文档不算）这些都是成本收益比很低的东西，代码模型文档更是纯垃圾。

非技术的问题，不要想通过技术解决。

两种都要有。第一种相当于将还款计划和还款历史这两个实体合并成一个实体，未尝不可，当然分成两个实体也可以，但是，还款计划这个数据是必须有的。第二种的数据，是以用户为维度的逾期情况，这个数据是很有必要存在的，不然你逾期提醒都不好做。

如果参考信用卡，你还需要一份数据，账单。当然你们要不是正规金融机构的话，还款计划、还款记录、账单，这三个可以合并成一个实体来处理。以用户为维度的逾期情况这个实体，就没法合并了，要合并它也是合并到用户实体上。

其实这个设计过程，跟数据库没关系。你得先设计好了这些实体关系，然后再去往数据库上映射。

这跟技术，貌似没有关系。如果不考虑渠道，那么自动续费的每次自动扣费过程，跟一次性付费过程，是一样的，都是商家端发起用户端同意渠道端转账，只是前者事先做了三方协议从而可以让用户端自动同意。简单的说：一，定价权掌握在商家端那里；二，每次扣费都是独立账单。在苹果、微信、支付宝渠道上，渠道端会拿走一部分定价权，但这仍然是商务，跟技术没关系。

商务的东西，万事皆可商量。你看到的订阅规则，跟大客户看到的订阅规则，是不一样的。

你网上的说法不对。第一，around before/after 必定与 before/after 对应出现，要么 around 在外，即 around before — before — after — around after ，要么 around 在内，即 before — around before — around after — after ，你网上那种顺序不符合常理 。第二，先执行方法后执行 after 切面，同时 return 是在方法内部的，所以 afterReturning 早于 after 更复合常规。

数据大屏本身是个没啥用的东西，但是要把它支撑起来，下面需要完善的业务系统和 OLAP/大数据分析系统，以及最重要的，持续集成或持续开发。你需要的是一个能够全权负责乙方的高级 IT 主管，不是干杂事的码农。

上面 JVM 堆内存描述有误，应该时：启动时只占用 -Xms 指定的大小，后面随需要扩大占用，直到 -Xmx 指定的大小。

#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 2863661056 bytes for committing reserved memory.
# Possible reasons:
# The system is out of physical RAM or swap space
# In 32 bit mode, the process size limit was hit
# Possible solutions:
# Reduce memory load on the system
# Increase physical memory or swap space
# Check if swap backing store is full
# Use 64 bit Java on a 64 bit OS
# Decrease Java heap size (-Xmx/-Xms)
# Decrease number of Java threads
# Decrease Java thread stack sizes (-Xss)
# Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
#
# Out of Memory Error (os_linux.cpp:2640), pid=18191, tid=0x00007f6c15c70700
#
# JRE version: (8.0_172-b11) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.172-b11 mixed mode linux-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

这一段已经说明错误现象，可能的原因，和大致的解决方案了。

现象：JVM 向基本系统申请内存的时候失败了，2863661056 bytes 大概 356 MB 。
这里申请的不是 -Xms -Xmx 指定的 JVM 堆内存，而是 JVM 需要占用的其他内存，JVM 堆内存在 JVM 启动的时候就独占了，后面不会再申请。Java 实例化后的对象（实际上是对象的成员变量），方法运行期间的变量，这俩是放到 JVM 堆内存的。但是 Java 类定义本身（类结构、类当中方法的函数定义、类的静态变量这些），是放到额外内存中的。此外 JVM 本身也会占用内存。后两个内存是动态的，现在要申请的可能就是这俩内存，然后因超出物理机或者进程内存上限而失败了。

原因就两个：一，物理机内存，包括实际物理内存和交换区（ Windows 下就是虚拟内存），都满了；二，32 位程序，单进程内存通常上限是 4G 。

如果单看编程，base64 编码进 json 里面，省事的不光前端，也有后端，而且后端省事的更多。这个的问题是，随着文件的增大，接口的处理时间、服务器的并发能能力、网关、日志等多处地方的性能都会收到影响，而且通常影响程度至少是指数级。这东西是要在编程省事和性能优化之间做权衡的，做这个权衡的，应该是架构师或者有过经验的人，不是是当事开发前后端双方。

公司专利，主要不看谁写，看专利作者是谁。手下写专利领导领奖金，不过就是教授剽窃学生论文的翻版而已。

此外，不管专利作者是谁，在公司写的专利的所有权都是公司，意味着：专利一旦通过里面的发明方法就必须有公司的授权才能用，哪怕你是原始发明者。所以，除非是打算干到养老的公司，别把自己的压箱底本是拿来给公司申请专利。

大致看了一下，这东西还是可以用的。理念上有两部分，一， 从 O 半到 M：隐藏 SQL ； O 端托管状态；没有 O-M 强关联。 二，对象模型是参考 JSON 或者 树的动态对象。

这里的重点还是这个对象模型，如果业务上的数据模型就是这种树模型的话，它这个用起来倒是很不错。但是很不幸的是，Java 体系面向的业务，有心的话是领域模型或 ER 模型，无心的话直接用关系模型（就算没有数据模型的纯靠界面原型或者扣扣相传的小作坊，背后也是不知不觉用着关系数据模型），在这些模型上它这个框架基本用不了，如果硬要用，那就真成了集 JPA 和 Mybatis 的缺点与一身。

预测，不是结论：同时对打两个东西的缺点，往往会变成同时去掉两个框架的优点并集中它们的缺点。

Paypal 支付跟国内支付不一样，不是完全隐藏转出账户端，商家是能选择转出账户的类型，以及账单地址的。你这情况应该是 Cloudflare 不接受银联借记卡渠道。

@RRyo #23 中国本地节假日跟中国国务院每年颁布的含调休的法定节假日，两者的区别，以及楼主想要的是哪个，不需要多么高的智商就该知道吧。

@x1024m #10
@leeyuzhe #14
不要碰瓷农历，现行农历无正朔，19 年一个循环规律的很。全世界需要年年定、而且还是以天为单位调整的节假日，这独一份的东西不叫作本地化。

给 UI 看的，不是标准原型就是手绘草图，正好被楼主给全否了。建议直接耳提面命。

C 盘啥时候变内存了

请谨记，PVP 游戏和互联网产品中，你是产品，不是玩家 /用户。摆不正这个位置，你就会变成上学时喜欢打小报告的那种跳梁小丑。

有一个比较重的方式，如果只是初始化一两个全局变量的话没必要，如果是参与系统架构调整的话，可以考虑。

定义并注册 Spring 容器启动事件监听，再监听中处理，可以一个监听处理多个场景的初始化。
定义监听类：public class ApplicationContextRefreshed implements ApplicationListener<ContextRefreshedEvent>
注册监听：启动类修改成如下，
public static void main(String[] args) {
SpringApplication springApplication = new SpringApplication(Application.class);
springApplication.addListeners(new ApplicationContextRefreshed());
springApplication.run(args);
}



还有一种更简单的配置方式，定义下面这个构造器即可：
@Autowird
public DemoParam(@Autowird DaoOrJpaRepistory daoOrRepo ){
flag = daoOrRepo.xxxx;
}