 |
yuanxiaosongV2EX 第 513493 号会员，加入于 2020-10-20 08:45:55 +08:00 |
yuanxiaosong 最近回复了
67 天前 回复了 malagebidi 创建的主题 › 成都 › 成都有萝卜快跑了吗，准备去体验一下 |
新川路对面天天都在试车，就是不知道在运营没有
67 天前 回复了 mrjade 创建的主题 › macOS › Mac 开机，向日葵在没有启动的情况下，一直在尝试连接服务 |
你以为它没启动，其实它是通过 service 的方式注册了，不过清理了过后向日葵就打不开了，可以尝试备份到其他文件夹，要使用向日葵的时候再还原回去。
67 天前 回复了 mrjade 创建的主题 › macOS › Mac 开机，向日葵在没有启动的情况下，一直在尝试连接服务 |
#!/bin/bash
# 检测是否以 sudo 运行
if [ "$(id -u)" != "0" ]; then
echo "请以 sudo 执行当前脚本" 1>&2
exit 1
fi
echo 正在清理向日葵开机启动项
rm -rf /Library/LaunchAgents/com.oray.sunlogin.agent.plist
rm -rf /Library/LaunchAgents/com.oray.sunlogin.startup.plist
rm -rf /Library/LaunchDaemons/com.oray.sunlogin.helper.plist
rm -rf /Library/LaunchDaemons/com.oray.sunlogin.plist
# 检测是否以 sudo 运行
if [ "$(id -u)" != "0" ]; then
echo "请以 sudo 执行当前脚本" 1>&2
exit 1
fi
echo 正在清理向日葵开机启动项
rm -rf /Library/LaunchAgents/com.oray.sunlogin.agent.plist
rm -rf /Library/LaunchAgents/com.oray.sunlogin.startup.plist
rm -rf /Library/LaunchDaemons/com.oray.sunlogin.helper.plist
rm -rf /Library/LaunchDaemons/com.oray.sunlogin.plist
67 天前 回复了 289396212 创建的主题 › 程序员 › 如何快速理解并掌握 DDD 后端开发？ |
在我看来，DDD 是一种设计，让你如何去规划这个系统，比如我们在使用微服务的时候，如何决定一个服务到底有多大，能做多少事情，它的边界在哪里，这个就可以用 DDD 来解决，比如我们在做单体服务的时候，如果有两个 service 需要业务上循环依赖，怎么去把它俩的依赖解开，确定每个 service 到底该干那些事。
DDD 是教你怎么去做做设计，不是写两个 command 、domain 就叫 DDD ，贫血/充血什么的只是具体的工具，我经常问别人，现在我们系统是基于面向过程语言编写的，它没有对象模型这种，它就不配用 DDD 了？
记得前几年看过一个大佬这样描述 DDD 的：DDD 是战略，贫血/充血是战术。
可以看一篇 infoq 的文章“DDD 和微服务之间是什么关系？”
DDD 的本质是一种软件设计方法，而微服务架构是具体的实现方式。微服务架构虽好，但是他并没有给出如何对复杂系统进行分解的具体方法论，而 DDD 正好就是解决方案。
https://www.infoq.cn/article/34uhkxy98uztabz_mpui
DDD 是教你怎么去做做设计，不是写两个 command 、domain 就叫 DDD ，贫血/充血什么的只是具体的工具，我经常问别人，现在我们系统是基于面向过程语言编写的，它没有对象模型这种，它就不配用 DDD 了？
记得前几年看过一个大佬这样描述 DDD 的：DDD 是战略，贫血/充血是战术。
可以看一篇 infoq 的文章“DDD 和微服务之间是什么关系？”
DDD 的本质是一种软件设计方法，而微服务架构是具体的实现方式。微服务架构虽好，但是他并没有给出如何对复杂系统进行分解的具体方法论，而 DDD 正好就是解决方案。
https://www.infoq.cn/article/34uhkxy98uztabz_mpui
69 天前 回复了 YJi 创建的主题 › 程序员 › 借着首页在讨论跨域,一个运维朋友教我写的配置合适不? |
@salmon5 我倒是觉得小公司才在后端服务里面写跨域，一般来说环境有开发/测试/预发布/生产（蓝/绿）/演示环境等，并且一个公共服务 API 会被多个产品调用，每个产品一级域名都不一样，有些产品客户还有私有化部署需求，还没考虑私有化部署需求，难道让后端把所有域名都收集好写到代码/配置里面，每次新增一个域名都改一次后端服务？众所周知，Access-Control-Allow-Origin 只能是单个域名或者*，如果一个 api 对应多个不同一级域名，代码还要
if (ALLOW_ORIGINS.contains(requestDomain)) {
resp.addHeader("Access-Control-Allow-Origin", requestDomain);
}
这种写法，不难受么？
if (ALLOW_ORIGINS.contains(requestDomain)) {
resp.addHeader("Access-Control-Allow-Origin", requestDomain);
}
这种写法，不难受么？
69 天前 回复了 YJi 创建的主题 › 程序员 › 借着首页在讨论跨域,一个运维朋友教我写的配置合适不? |
@coolcoffee 正常正好相反，一个后端 API 可能对应 n 个业务线，每个业务线又有 n 个产品，鬼才知道前端用的什么域名，所以我们的操作是使用 proxy_hide_header ，不管后端服务设置什么跨域全部丢弃掉。
133 天前 回复了 ljzxloaf 创建的主题 › 程序员 › 如何管理 springboot 项目的配置文件 |
不使用 spring cloud/docker/k8s 管理配置
1. 使用外部 env 文件管理：
application.yml
```
spring:
config:
import: optional:file:.env[.properties]
datasource:
url: ${DATASOURCE_URL:jdbc:mysql://127.0.0.1:3306/demo?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=GMT%2B8}
username: ${DATASOURCE_USERNAME:root}
password: ${DATASOURCE_PASSWORD:root}
```
.env
```
DATASOURCE_USERNAME=test
DATASOURCE_PASSWORD=test
```
优先使用 env 中的值，如果 env 中未找到对应值，则使用 yml 中的值，根据不同环境指定不同的 env 文件；
2. 启动时候通过启动参数配置
java -jar xxx.jar --spring.datasource.username=test --spring.datasource.password=test
1. 使用外部 env 文件管理：
application.yml
```
spring:
config:
import: optional:file:.env[.properties]
datasource:
url: ${DATASOURCE_URL:jdbc:mysql://127.0.0.1:3306/demo?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=GMT%2B8}
username: ${DATASOURCE_USERNAME:root}
password: ${DATASOURCE_PASSWORD:root}
```
.env
```
DATASOURCE_USERNAME=test
DATASOURCE_PASSWORD=test
```
优先使用 env 中的值，如果 env 中未找到对应值，则使用 yml 中的值，根据不同环境指定不同的 env 文件；
2. 启动时候通过启动参数配置
java -jar xxx.jar --spring.datasource.username=test --spring.datasource.password=test
142 天前 回复了 kachu673 创建的主题 › Java › Spring 开发，流程冗余 |
@chaleaochexist
问题 1：在保证一个 dao 对应一个表（仅限增删改）的前提下，这个确实有很大的争论点，没有一个固定的答案，它可以叫 UserDept ，也可以 DeptUser ，但是在我看来，理论上只有一个存在，除非你底层用双向链表来维护（有两个数据库表），你用 User 打头，那么你潜意识就认为这个关联关系应该由 UserManager 来维护，反之亦然。
继续问题 1：首先确定，Service 只和 Manager 打交道，类似于事件驱动，Service 会通知每一个 Manager ，我现在要删除一个部门了，真正的执行人是 Manager ，如果关联关系是 DeptManager 维护，那么它会删除 dept 表和 dept_user ，UserManager 说关联关系不是我维护的，我直接 return ，不做任何操作，反之亦然，删除这个工作并不是 service 来完成，真正的删除是在 UserManager 和 DeptManager 中，为什么只调用某个 manager 是我们很明确其他 manager 没有和部门发生关系而已。
继续问题 1：我们目前使用一个原则来确认代码在那一层：是否抛出业务异常和 Manager 中一个方法只能对应一个动作（增/删/改）
问题 2：来个简单粗暴的，直接调用 dao 的都在 manager 中，功能权限校验/参数校验/返回结果裁剪都在 controller 中，其他的都扔在 service 中就可以了，不要过多纠结，这个没有统一标准，写的多了自然就有经验了。
问题 1：在保证一个 dao 对应一个表（仅限增删改）的前提下，这个确实有很大的争论点，没有一个固定的答案，它可以叫 UserDept ，也可以 DeptUser ，但是在我看来，理论上只有一个存在，除非你底层用双向链表来维护（有两个数据库表），你用 User 打头，那么你潜意识就认为这个关联关系应该由 UserManager 来维护，反之亦然。
继续问题 1：首先确定，Service 只和 Manager 打交道，类似于事件驱动，Service 会通知每一个 Manager ，我现在要删除一个部门了，真正的执行人是 Manager ，如果关联关系是 DeptManager 维护，那么它会删除 dept 表和 dept_user ，UserManager 说关联关系不是我维护的，我直接 return ，不做任何操作，反之亦然，删除这个工作并不是 service 来完成，真正的删除是在 UserManager 和 DeptManager 中，为什么只调用某个 manager 是我们很明确其他 manager 没有和部门发生关系而已。
继续问题 1：我们目前使用一个原则来确认代码在那一层：是否抛出业务异常和 Manager 中一个方法只能对应一个动作（增/删/改）
问题 2：来个简单粗暴的，直接调用 dao 的都在 manager 中，功能权限校验/参数校验/返回结果裁剪都在 controller 中，其他的都扔在 service 中就可以了，不要过多纠结，这个没有统一标准，写的多了自然就有经验了。
142 天前 回复了 kachu673 创建的主题 › Java › Spring 开发，流程冗余 |
@chaleaochexist 比较有争议的是这种情况，UserDao/DeptDao/UserDeptDao ，UserDao 和 UserDeptDao 肯定是直接被 UserManager 引用，现在有个需求，在部门下有人的情况下，可以直接删除部门，删除部门后，需要将部门下的人员与部门关系解除，很多人就会这样写：
class DeptManager{
void deleteDept(id){
deptDao.deleteById(id);
userDeptDao.deleteByDeptId(id);
}
}
实际上我们做法是这种；
class DeptService{
void deleteDept(id){
deptManager.deleteById(id);
userManger.deleteUserDeptByDeptId(id);
}
}
由上层去协调，如果还有业务逻辑掺杂在里面，我们还有更上层的应用层去协调：
class DeptApplication {
void deleteDept(id){
deptService.deleteById(id);
userService.deleteUserDeptByDeptId(id);
}
}
class DeptManager{
void deleteDept(id){
deptDao.deleteById(id);
userDeptDao.deleteByDeptId(id);
}
}
实际上我们做法是这种；
class DeptService{
void deleteDept(id){
deptManager.deleteById(id);
userManger.deleteUserDeptByDeptId(id);
}
}
由上层去协调，如果还有业务逻辑掺杂在里面，我们还有更上层的应用层去协调：
class DeptApplication {
void deleteDept(id){
deptService.deleteById(id);
userService.deleteUserDeptByDeptId(id);
}
}
142 天前 回复了 kachu673 创建的主题 › Java › Spring 开发，流程冗余 |
@chaleaochexist 理论上一个 dao 不会被两个 manager 调用，这个就要从上层设计来说了，领域驱动设计(DDD)应该有了解吧，我们完整的领域对象应该包括了（属性+业务方法），大概是长这个样子：
class User {
Long id;
String name;
void saveUser(){
// so something
userDao.saveUser();
userDeptDao.saveUserDept();
}
}
后来我们觉得应该职责分离，属性和方法分开，就变成了下面这种：
class User{
Long id;
String name;
}
class UserService extends User {
void saveUser(){
// so something
userDao.saveUser();
userDeptDao.saveUserDept();
}
}
再后来我们觉得方法还可以继续拆，分为业务方法和非业务方法：
class UserManager extends User {
void saveUser(){
userDao.saveUser();
userDeptDao.saveUserDept();
}
}
class UserService extends UserManager {
void saveUser(){
// so something
userManager.saveUser();
}
}
看出来没有，我们所有的操作其实都围绕着 User 这个模型在工作，如果你有 UserAManager 和 UserBManager ，这两个都调用 UserDao 可以，但是你一个 DeptManager 调用 UserDao ，那就要考虑一下是不是你的模型设计有问题了？
class User {
Long id;
String name;
void saveUser(){
// so something
userDao.saveUser();
userDeptDao.saveUserDept();
}
}
后来我们觉得应该职责分离，属性和方法分开，就变成了下面这种：
class User{
Long id;
String name;
}
class UserService extends User {
void saveUser(){
// so something
userDao.saveUser();
userDeptDao.saveUserDept();
}
}
再后来我们觉得方法还可以继续拆，分为业务方法和非业务方法：
class UserManager extends User {
void saveUser(){
userDao.saveUser();
userDeptDao.saveUserDept();
}
}
class UserService extends UserManager {
void saveUser(){
// so something
userManager.saveUser();
}
}
看出来没有，我们所有的操作其实都围绕着 User 这个模型在工作，如果你有 UserAManager 和 UserBManager ，这两个都调用 UserDao 可以，但是你一个 DeptManager 调用 UserDao ，那就要考虑一下是不是你的模型设计有问题了？
Select Language