OneCode开源低代码引擎白皮书
随着低代码概念的火热，相关的技术及产品也是层出不穷，不管是老牌行业软件厂商还是开放平台厂商，不论是互联网行业企业SAAS软件新动向还是新兴的低代码创新产品服务,都在第一时间打出了低代码这张牌。各个平台虽然各有优势，但大多又是自成体系，真正在企业方面进行选择时却一时难以抉择。对于低代码平台的功能评价，以及各平台组件间的互联互通则成为了市场上迫切需求。
在刚刚过去的2022年，在平台互联互通的方面，阿里在第二季度推出开源引擎 “LowCodeEngin”，国家队信通院也应市场需求在第四季度推出了《低代码开发平台通用技术要求》，针对低代码相关概念以及功能点新型了进一步的规范和梳理。
OneCode 低代码引擎元数据设计
前言：
在百度百科中，元数据被定义为：描述数据的数据，对数据及信息资源的描述性信息。在低代码平台中元数据的使用也是非常广泛，从前端可视化的组件的prop 属性定义，后端OR Maping数据库表映射,以及支撑系统模块关联关系，权限分配支撑等等都是基础性的元数据。而对于低代码平台及工具而言，其最主要的一个功能也是配置管理低代码组件的元数据信息。在业务组件发生需求变更时尽量通过修改元数配置的方式来改变组件的业务特性。
宜搭核心设计和思考
宜搭首席技术官谈宜搭核心设计和思考，宜搭平台是搭建企业协同办公领域应用的PAAS平台，自今年3月上云以来，宜搭已持续为近30位合作伙伴助力解决方案的提供，服务客户涉及新零售、医疗、银行、制造、酒店等多个领域。这里总结下最近两年的企业应用实践经验，分享下宜搭的设计以及背后的思考，欢迎大家讨论。
领域驱动设计(DDD)-基础思想
一、序言
领域驱动设计是一种解决业务复杂性的设计思想，不是一种标准规则的解决方法。在领域驱动设计理念上，各路大侠的观点也是各有不同，能力有限、欢迎留言讨论。
二、领域驱动设计
DDD是什么
wiki释义：
领域驱动设计（英语：Domain-driven design，缩写 DDD）是一种通过将实现连接到持续进化的模型[1]来满足复杂
如何形成统一设计风格-实践篇
在上一篇《业务团队如何统一架构设计风格？》中，探讨了一种业务架构的设计规范，以期达到这些目标：用标准约束技术细节；用技术工具而非文档推行标准；持续重构而非造新轮子；重视业务建模。但通篇表述较为抽象。本篇将总结团队近来的架构演进工作，以更具体的技术细节，详细阐释该理念，作为“统一业务设计风格”的实践篇。文中详述了多个层面的设计规约和基于规约的搭建方式，并在末尾回答了上一篇的诸多疑问。
DDD 领域驱动设计落地实践系列：工程结构分层设计
前面几篇文章中，笔者给大家阐述了 DDD 领域驱动设计的三大过程，重点围绕如何通过战略设计与战术设计进行 DDD 落地实践进行了详细的讨论，但是还没有涉及到工程层面的落地。实际上所有的这些架构理论到最后都是为了使得我们代码结构更加清晰，从而开发出 bug 少、扩展性强、逻辑清楚的应用。因此本文就是为了解决 DDD 领域驱动落地实践最后一公里问题，将我们分析出来的领域模型通过与工程结构的映射实现真正的落地。
DDD、中台和微服务的关系是什么？
领域驱动设计（DDD）和中台在企业架构中有着密切的关系。DDD的本质在于通过对业务领域的深入分析和建模，构建高内聚、低耦合的系统。而中台则是对企业核心业务能力的抽象和封装，以实现业务能力的复用和扩展。
