ReactJs is a JavaScript library for building user interfaces that uses components and a virtual DOM for efficient updates. It is intended to make development of UI components easy and modular. React implements unidirectional data flow and uses components, a virtual DOM, JSX syntax, and isomorphic rendering to provide a declarative and efficient way to build user interfaces.
ReactJs is a JavaScript library for building user interfaces that uses components and a virtual DOM for efficient updates. It is intended to make development of UI components easy and modular. React implements unidirectional data flow and uses components, a virtual DOM, JSX syntax, and isomorphic rendering to provide a declarative and efficient way to build user interfaces.
The document provides an overview of state management in Angular using NgRx. It discusses setting up the store and reducers, accessing state in components, using selectors, handling asynchronous operations with effects, improving data persistence with NX, and connecting related data models. The key steps covered include creating interfaces and initial state, setting up the reducer, importing modules, dispatching actions, using entity adapters for collections, and composing selectors.
여러 언어에서 null 안전성을 주요 마케팅 쟁점으로 내세우면서 null 안전성이 관심을 많이 받고 있습니다.
자바에서도 null을 잘 다루어야 소프트웨어 결함을 줄이고 견고하게 만들 수 있는데 null의 위협에서 코드를 안전하게 지키는 설계 지침을 정리하고 안전하다고 확인하는데 도움이 되는 도구를 소개합니다.
Decomposing Applications for Scalability and Deployability (April 2012)Chris Richardson
Today, there are several trends that are forcing application architectures to evolve. Users expect a rich, interactive and dynamic user experience on a wide variety of clients including mobile devices. Applications must be highly scalable, highly available and run on cloud environments. Organizations often want to frequently roll out updates, even multiple times a day. Consequently, it’s no longer adequate to develop simple, monolithic web applications that serve up HTML to desktop browsers. In this talk we describe the limitations of a monolithic architecture. You will learn how to use the scale cube to decompose your application into a set of narrowly focused, independently deployable back-end services and an HTML 5 client. We will also discuss the role of technologies such as NodeJS and AMQP brokers. You will learn how a modern PaaS such as Cloud Foundry simplifies the development and deployment of this style of application.
The document discusses Domain Driven Design (DDD). It explains that DDD involves creating a domain model that offers a simplified view of the problem domain. The domain model can be represented through text, diagrams like UML class diagrams, or code. Common DDD building blocks include entities, values, services, and repositories. Entities have identities and life cycles, values represent characteristics without identities, services encapsulate specific tasks, and repositories provide global access to entities. The document also discusses layered architectures and using DDD to build a flexible design that matches the problem domain.
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
React Class Components vs Functional Components: Which is Better?Fibonalabs
Earlier, class components were the only option to add states to components and manipulate the lifecycle. However, since the introduction of React Hooks, now we can add the same functionality to function components.
This document discusses state management in Angular and React applications. It introduces state and its problems, describes the Redux architecture for effective state management, and provides an overview of implementing state management in Angular using NgRx. The document also includes an agenda, information about the presenters, definitions of state and common approaches to managing it. It then demonstrates state management for a social media app using NgRx, covering components, data workflow, actions, reducers, and selecting state. It concludes by providing live demo links and additional resources.
CQRS and Event Sourcing, An Alternative Architecture for DDDDennis Doomen
Most of us will be familiar with the standard 3- or 4-layer architecture you often see in larger enterprise systems. Some are already practicing Domain Driven Design and work together with the business to clarify the domain concepts. Perhaps you’ve noticed that is difficult to get the intention of the 'verbs' from that domain into this standard architecture. If performance is an important requirement as well, then you might have discovered that an Object-Relational Mapper and a relational database are not always the best solution.
One of the main reasons for this is the fact that the interests of a consistent domain that takes into account the many business rules, and those of data reporting and presentation are conflicting. That’s why Betrand Meyer introduced the Command Query Separation principle.
An architecture based on this principle combined with the Event Sourcing concept provides the ideal architecture for building high-performance systems designed using DDD. Well-known bloggers like Udi Dahan and Greg Young have already spent quite a lot of of posts on this, and this year’s Developer Days had some coverage as well.
But how do you build such a system with the. NET framework? Is it really as complex as some claim, or is just different work?
The document provides an overview of state management in Angular using NgRx. It discusses setting up the store and reducers, accessing state in components, using selectors, handling asynchronous operations with effects, improving data persistence with NX, and connecting related data models. The key steps covered include creating interfaces and initial state, setting up the reducer, importing modules, dispatching actions, using entity adapters for collections, and composing selectors.
여러 언어에서 null 안전성을 주요 마케팅 쟁점으로 내세우면서 null 안전성이 관심을 많이 받고 있습니다.
자바에서도 null을 잘 다루어야 소프트웨어 결함을 줄이고 견고하게 만들 수 있는데 null의 위협에서 코드를 안전하게 지키는 설계 지침을 정리하고 안전하다고 확인하는데 도움이 되는 도구를 소개합니다.
Decomposing Applications for Scalability and Deployability (April 2012)Chris Richardson
Today, there are several trends that are forcing application architectures to evolve. Users expect a rich, interactive and dynamic user experience on a wide variety of clients including mobile devices. Applications must be highly scalable, highly available and run on cloud environments. Organizations often want to frequently roll out updates, even multiple times a day. Consequently, it’s no longer adequate to develop simple, monolithic web applications that serve up HTML to desktop browsers. In this talk we describe the limitations of a monolithic architecture. You will learn how to use the scale cube to decompose your application into a set of narrowly focused, independently deployable back-end services and an HTML 5 client. We will also discuss the role of technologies such as NodeJS and AMQP brokers. You will learn how a modern PaaS such as Cloud Foundry simplifies the development and deployment of this style of application.
The document discusses Domain Driven Design (DDD). It explains that DDD involves creating a domain model that offers a simplified view of the problem domain. The domain model can be represented through text, diagrams like UML class diagrams, or code. Common DDD building blocks include entities, values, services, and repositories. Entities have identities and life cycles, values represent characteristics without identities, services encapsulate specific tasks, and repositories provide global access to entities. The document also discusses layered architectures and using DDD to build a flexible design that matches the problem domain.
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
React Class Components vs Functional Components: Which is Better?Fibonalabs
Earlier, class components were the only option to add states to components and manipulate the lifecycle. However, since the introduction of React Hooks, now we can add the same functionality to function components.
This document discusses state management in Angular and React applications. It introduces state and its problems, describes the Redux architecture for effective state management, and provides an overview of implementing state management in Angular using NgRx. The document also includes an agenda, information about the presenters, definitions of state and common approaches to managing it. It then demonstrates state management for a social media app using NgRx, covering components, data workflow, actions, reducers, and selecting state. It concludes by providing live demo links and additional resources.
CQRS and Event Sourcing, An Alternative Architecture for DDDDennis Doomen
Most of us will be familiar with the standard 3- or 4-layer architecture you often see in larger enterprise systems. Some are already practicing Domain Driven Design and work together with the business to clarify the domain concepts. Perhaps you’ve noticed that is difficult to get the intention of the 'verbs' from that domain into this standard architecture. If performance is an important requirement as well, then you might have discovered that an Object-Relational Mapper and a relational database are not always the best solution.
One of the main reasons for this is the fact that the interests of a consistent domain that takes into account the many business rules, and those of data reporting and presentation are conflicting. That’s why Betrand Meyer introduced the Command Query Separation principle.
An architecture based on this principle combined with the Event Sourcing concept provides the ideal architecture for building high-performance systems designed using DDD. Well-known bloggers like Udi Dahan and Greg Young have already spent quite a lot of of posts on this, and this year’s Developer Days had some coverage as well.
But how do you build such a system with the. NET framework? Is it really as complex as some claim, or is just different work?
2015 년 오픈클라우드 엔진 핸드북입니다. 지난 2012년 부터 3년간의 국산 오픈소스 플랫폼 제품들을 클라우드 컴퓨팅의 주제로 통합하고 있는 프로젝트입니다. 본 자료는 기업과 서비스 제공자 들의 클라우드 컴퓨팅 전환에 있어 요구되는 사항들을 짚어보고, 2015년 지금까지 노력해온 오픈클라우드엔진의 제품들이 어떻게 그 요구사항들에 부합될 수 있는지에 대한 내용을 담고 있습니다.
2. 대규모 구조
• 설계를 관리 가능한 응집력 있는 MODULE로 분해
• 굉장히 많은 MODULE이 생겨남
• 기능의 특정 측면을 보려면 어떤 패키지를 찾아야 할까?
• 새 클래스는 어디다 둬야 할까?
• 이런 작은 패키지 중 일부는 실제로 어떤 의미가 있는가?
• 그와 같은 패키지는 서로 얼마나 잘 어울릴까?
• MODULAR를 중심으로 분해하더라도
큰 모델은 파악하기에 너무 복잡할 수 있다!
3. 대규모 구조
• 프로젝트의 규모와 상관없이 사람들은 시스템의 다른 부분에서 어
느 정도 독립적으로 일해야 한다
• 큰 시스템에, 해당 시스템의 요소를 전체 설계에 걸친 패턴에서의
역할 측면에서 해석하게 할 수 있는 지배적익 원칙이 없다면 개발
자들은 나무만 보고 숲을 보지 못한다.
• 전체의 세부 사항을 깊이 파고들지 않고도 전체의 각 부분이 담당
하는 역할을 이해할 수 있어야 한다
4. 대규모 구조의 패턴
SYSTEM
METAPHOR
MODEL-DRIVEN RESPONSIBILITY
DESIGN LAYER
EVOLVING
ORDER KNOWLEDGE
LEVEL
PLUGGABLE
COMPONENT
FRAMEWORK
5. EVOLVING ORDER 발전하는 질서
• 구조화 되지 않은 설계에서 발생하는 비용을 경험한 적이 있는가?
• 이런 혼란을 피하고자 프로젝트에서는 다양한 방법으로 개발을
제약하는 아키텍처를 부과한다
• 아무나 설계할 수 있다면
– 누구도 전체적으로 이해할 수 없는 시스템이 만들어지고
– 이런 시스템은 유지보수 하기 어렵다
• 그러나 아키텍처는 사전 설계와 관련한 가정을 둠으로써 프로젝트
를 속박할 수 있고, 애플리케이션의 특정 부분에 대해 개발자/설계
자의 권한을 너무 많이 앗아갈 수 있다.
6. EVOLVING ORDER 발전하는 질서
• 개념적인 대규모 구조가 애플리케이션과 함께 발전하게 해서 발전
과정에서 전혀 다른 형식의 구조로도 변화할 수 있게 하라.
• 반드시 세부적인 지식을 토대로 내려야 할 세부적인 설계 및 모델
과 관련된 의사결정을 과도하게 제약해서는 안된다.
7. 대규모 구조의 패턴
SYSTEM
METAPHOR
MODEL-DRIVEN RESPONSIBILITY
DESIGN LAYER
EVOLVING
ORDER KNOWLEDGE
LEVEL
PLUGGABLE
COMPONENT
FRAMEWORK
8. SYSTEM METAPHOR 시스템 은유
• 소프트웨어 설계는 매우 추상적이고 파악하기 힘든 경향이 있다.
• 개발자와 사용자가 모두 시스템을 이해하고 시스템을 전체적으로
바라보는 시각을 공유할 구체적인 수단이 필요하다
• '시스템 은유'는 어찌됐건 일종의 비유에 불과하므로 다양한 모델
이 적절한 방법으로 '시스템 은유'에 매핑될 수 있다
• 어떤 시스템의 구체적인 비유가 나타나 팀원의 상상력을 포착하고
유용한 방향으로 사고를 이끄는 것으로 보인다면 그것을 대규모
구조로 채택하라
9. 대규모 구조의 패턴
SYSTEM
METAPHOR
MODEL-DRIVEN RESPONSIBILITY
DESIGN LAYER
EVOLVING
ORDER KNOWLEDGE
LEVEL
PLUGGABLE
COMPONENT
FRAMEWORK
10. RESPONSIBILITY LAYER 책임 계층
• 각 개별 객체에 손수 만든 책임이 할당돼 있다면 가이드라인도 없
고, 균일함도 없고, 넓은 범위에 걸친 도메인을 동시에 다룰 능력
도 없는 셈이다. 큰 모델이 응집력을 부여하려면 그러한 책임 할당
에 특정 구조를 도입하는 것이 도움이 된다.
• 계층은 시스템 구획으로서...
• 모델에 존재하는 개념적 의존성과 도메인의 여러 부분에 대한 다
양한 변화율과 변화의 근원을 검토하라. 도메인에서 자연적인 층
을 식별하면 그것을 광범위한 추상적 책임으로 간주하라
• AGGREGATE, MODULE과 같은 각 도메인 객체의 책임이 한 계
층의 책임안에서 말끔히 맞아 떨어지로록 모델을 리팩터링하라
20. KNOWLEDGE LEVEL 지식 수준
• ENTITY 간의 역할과 관계가 각 상황마다 다양하게 작용하는 애
플리케이션에서는 복잡성이 폭발적으로 증가할 수 있다
• 완전히 일반화된 모델이나 고도로 맞춤화가 가능한 모델도 사용
자의 욕구를 충족하지 못한다
– 다른 타입을 참조하거나
– 각종 상황에서 여러가지 방법으로 쓰일 속성을 갖게 된다
• 기본적인 모델의 구조와 행위를 서술하고 제약하는 데 쓸 수 있는
별도의 객체 집합을 만들어라
• 이러한 관심사를 두가지 '수준'으로 분리해서 하나는 매우 구체적
으로 만들고 다른 하나는 사용자나 관리자의 맞춤화가 가능한 규
칙과 지식을 반영하게 만들어라
23. 대규모 구조의 패턴
SYSTEM
METAPHOR
MODEL-DRIVEN RESPONSIBILITY
DESIGN LAYER
EVOLVING
ORDER KNOWLEDGE
LEVEL
PLUGGABLE
COMPONENT
FRAMEWORK
24. PLUGGABLE COMPONENT FRAMEWORK
• 인터페이스와 상호작용에 대한 ABSTRACT CORE를 정제하고 그
러한 인터페이스의 다양한 구현이 자유롭게 대체될 수 있는 프레
임워크를 만들어라
• 이와 마찬가지로 컴포넌트가 ABSTRACT CORE의 인터페이스를
통해 정확히 작동하는 한 어떠한 애플리케이션에서도 그러한 컴포
넌트를 사용할 수 있게 하라.
• MAVEN ?
25. 구조는 얼마나 제약성을 지녀야 하는가?
• 여러가지 대규모 구조가 가능하고, 심지어 일반화된 구조 패턴 안
에서도 규칙을 얼마나 제약적으로 만드는가에 관한 선택의 여지는
많다
• 제약은 개발자가 필요로 하는 유연함을 앗아갈 수 있다
• 프레임워크를 만들고 대규모 구조의 구현을 엄격히 통제하고자 하
는 유혹을 이겨내야 한다
• 대규모 구조가 공헌하는 가장 중요한 바는 개념적 응집성과 도메
인에 대한 통찰력을 주는 것이다
26. 잘 맞아떨어지는 구조를 향한 리팩터링
• 최소주의
– 구조를 간단하고 가볍게
– 초반에는 '시스템은유'나 몇 가지 '책임계층'과 같은 느슨한 구조
• 의사소통과 자기 훈련
– 새로운 개발과 리팩터링을 할 때 반드시 구조를 따른다
– 대부분의 대규모 구조가 느슨한 개념적 지침이라서
팀은 반드시 '자기 훈련'을 수행해야 한다
27. 잘 맞아떨어지는 구조를 향한 리팩터링
• 재구조화가 유연한 설계를 낳는다
– 구조는 시스템의 복잡성이 증가하고 이해가 깊어질수록 발전한다
– 구조가 바뀔 때 전체 시스템은 새로운 질서를 따르도록 바뀌어야 한다
• 디스틸레이션은 부하를 줄인다
– 지속적인 디스틸레이션
